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1. Introduction 


Hi !, 

First of all I would like to comment that this tutorial is going to be about a tool that i met a 
few years ago from a presentation in BlackHat 2009. Unfortunately I was not lucky enough 
to go to that conference but I could read the papers that were presented there, one of 
them took my attention in particular. It was about an SDK designed for File Analysis and 
Unpacking, called TitanEngine from the people of ReversingLabs among them there is 
aPOx, (A well known Reverser and author of the famous tool RLPack). 

After we take a look of the Framework we’re going to see a little tool that I made which 
core is based in this framework, i use that to develop unpackers in an easy and quickly 
way without worrying too much of the functions implementations like dumping, add a 
section to the binary, etc.; these are the things that the framework does for us. 

Well, let's begin. 


1. Motivation for this work 


What it took me to write this material was the lack of information there is about the use of 
TitanEngine. Don’t understand this as a demerit to the work done by their creators, no, 
TitanEngine has their own documentation with all the functions explained and also we 
have the source code for the SDK which is the best we could have but... and there’s 
always a but, when someone starts working with something unknown, the first steps are 
often the most aggressive. Many people are not used to read documentation and less to 
try to understand how something works, that’s why I decided to create this tutorial to 
introduce in a more pleasant way and with some examples, the use of this SDK that 
without doubt, in my opinion, is a tool that we should not miss. 


1. What is TitanEngine SDK? 

TitanEngine (TE from now on) is an SDK that allows us to do several tasks analyzing 
software protections. Personally, i believe that the greatest potential of TE lies in the 
development of unpackers in a quick and easy manner, without worrying too much writing 
tedious and repetitive code routines like dumping, fixing the IAT, hooking a function, etc., 
but it not only allows us to do unpacking but 

many other things such as tools to repair lATs (as the case of ImportStudio) or tools like 
API Monitor type, or PE validators, etc. , there are many things we can do with TE and that 
is limited only by our own ideas. ©. 




a. Components of TitanEnqine 


TE consists basically of two major libraries: 

1) TitanEngine.dll 

2) TitaniumHooks.dll 

Both TitanEngine.dll and TitaniumHooks.dll come in different flavors: 


1) TitanEngine_x86.dll and TltanEngine_x64.dll 

2) TitaniumHooks_x86.dll and TitaniumEngine_x64.dll 

In short, we will call and include TitanEngine_x86.dll and TitanEngine_x64.dll within 
TitanEngine.dll, and TitaniumHooks_x86.dll and TitaniumHooks_x64.dll within 
TitaniumHooks.dll, but we must remember that each library is for a different architecture, 
we should choose the one that fits our needs. 

We could consider TitanEngine.dll as the core of the SDK, of the two libraries, 
TitanEngine.dll is the most important because it is the one that contains the largest 
number of SDK functions and with which we will be working mostly. TitaniumHooks.dll 
could be considered as an auxiliary library and as its name implies, it is intented to work 
with hooks (we will see later how to do that and what functions are those that we will use). 

In turn, TitanEngine.dll has functions that could encompass in the same category as they 
are designed to meet a certain assignments. This is how we can distinguish the following 
groups: 


a. 

Debugger 

b. 

Threads 

c. 

TLS 

d. 

Libraries 

e. 

OEP 

f. 

Process 

g- 

Dumper 

h. 

Importer 

i. 

Tracer 

j- 

Realigner 

k. 

Relocater 

1 . 

Exporter 

m. 

Resources 

n. 

Static 

o. 

Handler 

P- 

Extension 

q- 

Engine 
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Yes, i know, they are many, but not to panic :P 

It is not necessary that we know all the functions of the SDK but we should have an idea 
about what offers so when we require a function to solve a task, we could find it more 
quickly. 

In turn, TitaniumHooks.dll only has one module: 


a) Hooks 

Now, let’s see a brief description of each of the modules in TitanEngine.dll and 
TitaniumHooks.dll. 


• TitanEngine 

• Debugger Module : Basically, this group of functions are dedicated for process 

debugging and disassembly. It has functions for both debugging (obviously) and for 
disassembly (for which distorm is used internally ), 

functions to access the context of the process and functions to manipulate the 
process memory 

• Threader Module : This module, as is indicated by its name, consists of functions 
for working with threads. With the functions provided by this module we can identify 
threads, manipulate its context and even perform remote thread injections in other 
processes. 


• TLS Module : This module, as you have guessed, has functions for working with 
Thread-Local storage. For those who do not know what TLS is, basically, it is a 
mechanism by which we have local memory for exclusive use by a thread. As we 
know, all the threads of a process share the same range of virtual memory and in 
addition, each variable of a given function is accessible only by the thread that 
triggered this function but the global and static variables are shared by all threads 
of a process but with TLS we can create memory spaces for each thread of the 
process that only a particular thread can access through a global index. 

• Librarian Module : This group of functions is intended to work with libraries loaded 
by a given process. These functions allow us, for example, to set breakpoints in 
different events (when a library is loaded or un-loaded) or to get information about 
a loaded library (ImageBase, etc). 
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OEP Finder Module : This module has only two functions and basically it was 
created to allow us to get the original entry point (OEP) of a packed program in a 
generic way. 

Process Module: As its name implies, this module has functions to interact with 
processes. We can enumrate processes, or execute task within the context of a 
given process. 


Dumper Module : In this module, you could find functions to dump the whole 
memory space or a given memory region and even, functions to interact with 
certain fields of the PE structure and with the overlay data present in some packed 
programs (overlay data is extra data appended to the end of the file). 

Importer Module: This is one of the most important modules, together with the 
Debugger and the Dumper modules. It has functions to work with the Imported 
functions of a process. For example, we could search for lATs in an automatic way 
(a generic search) and fix (in a generic way too) malformed lATs. 


Tracer Module: This module includes a set of functions to detect and to fix API 
redirections, something very common these days with modern packers. It has an 
API tracer and something i think it is very cool and useful, you could use IREC 
plugins (plug it to TE) to try to fix the API redirections. Cool, isn't it? :P 

Fteligner Module: This module has functions to realign the PE and to validate the 
PE structure (in other words, to see if a given file is a valid PE file, a DLL or .EXE 
or something else). Something to remark about this module is that it works very 
good under x86 Oses while trying to validate files but, under x64 Oses, at least with 
the latest version 2.0.3 of TitanEngine, i have found some strange behaviour with 
certains PE+ files (Extended PE file - 64 Bits). 


Relocater Module: This module has functions to help us to handle the relocations. 
We can take memory snapshots and delete relocation tables. Without doubts, this 
is a module we will use a lot when we work with DLLs. 

Exporter Module: This module, as its name implies, has functions to work with and 
create export tables. 


Resourcer Module: This module has function to help us to extract information from 
the resource section of a PE. 



• Static Module: This module has functions to work with files statically. It can 
simulate the static load of a file without the need to use a debugger. This is very 
useful when we work with crypters. 


• Handler Module: This module has functions to work with handlers and mutexes 
created by processes. It can, for example, find processes that use a given mutex or 
close handles and mutexes locked to a file. 

• Extension Module: I don't know if we will use this module a lot, but, it has functions 
to do tests for the plugins created for TitanEngine (something like test cases). 


• Engine Module: In this module, we can group, aside from the “Engine Module” per 
se, the “Engine Unpacker Simplification Module” wich is a group of functions built 
from other functions from the SDK which let us do different tasks, for example, if 
you want to make an unpacker but you don't want to program the GUI, then, this 
module gives us with some standard functions to generate a GUI very quickly. 

That's all with the TitanEngine.dll, now, let see the other library. 

• TitaniumEngine. dll 

• Hooks Module: as we said earlier, this is the only module that TitaniumHooks.dll 
has and basically, it has some functions to work with hooks. Basically, we can hook 
APIs and functions in a process. 

1- What can i do with TitanEngine? 

Well, basically, the answer to the question is: for a start, you can build any tool you can 
imagine but... probably, there will be functions that will not be in the SDK but we will need 
them to complete our tasks, thus, is a good idea to create those functions and send them 
to the TE developers, then, this functions will be available (with luck) in next releases of TE 
or maybe, you can extend an actual function and fit to your needs and send them too. 

Anyways, we can create different types of tools, like the ones listed here. 

a- Unpackers: This is the most atractive thing of the SDK. In fact, the proyect i've 
started some time ago, FUU ( ) is nothing but a bunch 

of unpackers created with TE. We can create unpackers for almost every existing 
packers, crypters, compressors, etc;. Every plugin will have more o less functions 
of the TE SDK (plus your own defined functions) but without a doubt there will be 
less code lines that if we had to write every needed module by ourself, like the 
ones present in TE (Debugger, Dumper, Importer, etc.). 
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b- Hookers: Another type of tool that we could develop is a Hooker. It would be a type 
of tool to monitor API calls from a process (like APISpy) or even we could use it to 
analyse crashes in a process. Suppose that you have a crash in a program when it 
tries to write in an invalid memory position on the heap, then, with the Hooker 
module we could “hook” functions like Alloc() and Free() and to make modifications 
to see if that invalid memory position can be controlled by us. 


c- Tools: This is a very wide category, i know, even, we can group the two previous 
categories, but here, we can group any type of tool given a certain module of the 
SDK, for example, your own version of IREC, or a reduced version of a debugger, 
or even our little crypters. 

d- Plugins: In this category we can group those plugins that we could develop to plug 
into different tools like Oily, IREC, PEiD, TE itself, ImmDbg, etc. 


2- TitanEnqine v2.0.3 - What's new? 

Well, it is a little bit weird to start talking about an advanced version of this framework. TE 
already has three official releases: 

• TitanEngine 2.0.1 

• TitanEngine 2.0.2 

• TitanEngine 2.0.3 

Without doubts, the 2.0.3 release is the one that has something i have been looking 
forward. 

The three TE SDK releases have, mostly, the necessary headers to develop plugins in 
several programming languages like ASM (MASM x86; there is not x64 official support yet 
but Guan De Dio had worked in a un-official version for MASM x64), C, C++ and Delphi. 

The great news is that TE v2.0.3 has support for Python and LUA, two scripting languages 
widely used these days, definetely, this feature is a major step. We can work in real time 
with a process, interact with it without the need to assemble or compile every time we 
make a change in the source code. 

Later, we'll see the big difference that is to work in ASM, developing a plugin, and how to 
do it in Python, easily, just with some lines of code. You'll see that this is a great 
contribution to the SDK. 



3- Some functions of the SDK 


OK. The boring part is finished and the funny part is coming. Let's start to examine some 
of the functions that surely you are going to use. I’m not saying that with all these functions 
you will find a solution for all your problems, but as regards of unpacking (the principal 
subject of this tutorial), these functions will be the most used ir your plugins. 

To make it easier, we are going to split it in modules ?. 


Debuqqer's Mqdule Functiqns 


The following functions are the ones we are going to see: 


a) Disassemble 

b) StaticDisassemble 

c) InitDebug 

d) InitDLLDebug 

e) AutoDebugEx 

f) AttachDebugger 

g) DetachDebugger 

h) GetProcessInformation 

i) GetStartupInformation 

j) GetDebuggedDLLBaseAddress 

k) GetDebuggedFileBaseAddress 

l) DebugLoop 

m) StopDebug 

n) ForceClose 

o) SetBPX 

p) EnableBPX 

q) DisableBPX 

r) DeleteBPX 

s) SetMemoryBPX 

t) RemoveMemoryBPX 

u) SetPlardwareBreakpoint 

v) DeletePlardwareBreakpoint 

w) RemoveAllBreakpoints 

x) GetContextData 

y) SetContextData 

z) Find 

aa) GetJumpDestination 
bb) IsJumpGoingToExecute 
cc) SetCustomPlandler 
dd) PlideDebugger 
ee) UnPlideDebugger 
ff) GetPEBLocation 
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They are many but with the majority we can guess the job they can do. 


void* stdcall Disassemble(LPVOID DisassmAddress) 


The “Disassemble” function is used to disassemble a memory region that belongs to the 
debuggee process. As we can see, it has just one parameter, “DisassmAddress”, which is 
the memory address that we want to disassemble. If the function succeeds, the return 
value is a pointer to a string that represents the first disassembled instruction. If the 
function fails, the return value is NULL. 

The previous function is nothing but a wrapper of the “DisassembleEx”: 


void* stdcall DisassembleEx(HANDLE hProcess, LPVOID DisassmAddress, 
bool ReturnlnstructionType) 


As you can see, it has two extra parameters. The hProcess parameter is a HANDLE to the 
process from which we want obtain the “DisassmAddress”. 

Is worth it to clarify that the “Disassemble” function is used to retrieve the disassemble of 
an address present in the context of the debuggee, if we don't have a process to debug or 
the function fails because the address we indicate does not exist, then, “Disassemble” will 
fail. 

The “DisassembleEx” function is used to retrieve a disassembled of a given address from 
avery process we have access to, it is not necessary to be the current process. 


void* stdcall StaticDisassemble(LPVOID DisassmAddress) 


With this function, we can disassemble an address that is just in the context of the 
debuggee process. 

It has just one parameter called “DisassmAddress” in which we can indicate the address 
from where we want to obtain the disassembled instruction. If the function succeeds, it 
returns a pointer to a string with the representation of the disassembled instruction. If the 
function fails, the return value is NULL. 

Besides, we have “StaticDisassembleEx”: 


void* stdcall StaticDisassembleEx(ULONG^PTR DisassmStart, LPVOID 
DisassmAddress) 


The first parameter is “DisassmStart” and the second parameter is “DisassmAddress”. 
Thus, we can indicate the start and the end address to disassemble, it is like if we define a 
basic block to disassemble. If the function succeeds, the return value is a pointer to a 
string with the disassembled instructions. If the function fails, the return value is NULL. 






void* stdcall InitDebug(char* szFileName, char* szCommandLine, char* 
szCurrentFolder) 


The “InitDebug” function can be used to start the “Debug Session”. As we can see, it has 
the “szFileName” parameter which is a pointer to the string that contains the name of the 
executable we want to debug. The “szCommandLine” parameter is another pointer to a 
string with the command line for the process and finally, “szCurrentFolder” is a pointer to a 
string with the path to the current folder (this is needed for the CreateProcess call). 

If the function succeeds, the return value is a pointer to a PROCESS_INFORMATION 
structure: 


typedef struct _PROCESS_INFORMATION { 

HANDLE hProcess; 

HANDLE hThread; 

DWORD dwProcessId; 

DWORD dwThreadld; 

} PROCESS_INFORMATION, *LPPROCESS INFORMATION; 


If the function fails, the return value is NULL. 

If we take a look inside the “InitDebug” function, we will see that the only thing it does is to 
call the CreateProcess function with the following flags: 
DEBUG_PROCESS+DEBUG_THIS_PROCESS+DebugConsoleFlag. 

Besides, we have the “Ex” version, called “InitDebugEx”: 


void* stdcall InitDebugEx(char* szFileName, char* szCommandLine, char* 
szCurrentFolder, LPVOID EntryCallBack) 


This function receives the same parameters as “InitDebug” but we have an extra 
parameter called “EntryCallBack” which is a function “callback” that will be executed right 
after the process stops in the EntryPoint, after all it is the same to call “InitDebug” and then 
to set a breakpoint in the EntryPoint of the program. This function does not return a value. 


void* stdcall InitDLLDebug(char* szFileName, bool ReserveModuleBase, 
char* szCommandLine, char* szCurrentFolder, LPVOID EntryCallBack) 


The “InitDLLDebug” function is the counterpart of the “InitDebug” function. It is used to 
start the debug session for a DLL. It has exactly the same parameters as “InitDebugEx” 
but we have the “ReserveModuleBase” parameter which is a bool value that we can use to 
indicate if we want to load the DLL in the ImageBase indicated in its header or not. This 
function does not return a value 
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void stdcall AutoDebugEx(char* szFileName, bool ReserveModuleBase, 
char* szCommandLine, char* szCurrentFolder, DWORD TimeOut, LPVOID 
EntryCallBack) 


The “AutoDebugEx” function allow us to start a debug session for both DLLs and EXEs. It 
has the same parameters as “InitDebug” but we have the “EntryCallBack” from 
“InitDebugEx” and the “ReserveModuleBase” parameter from “InitDLLDebug”. This 
function does not return a value. 


bool stdcall AttachDebugger(DWORD Processld, bool KillOnExit, LPVOID 
Debuglnfo, LPVOID CallBack) 


The “AttachDebugger” function is responsible for starting a debug session attaching to a 
running process. For this, it requires a parameter called “Processld” which is the PID 
(process ID) of the process we want to attach to, another parameter is a bool value called 
“KillOnExit” that tells the function if it has to finish the debug session when the session 
ends, the “Debuglnfo” parameter is a pointer to a PROCESSJNFORMATION structure 
that will be filled if the function can successfuly attach to the process, finally, the “CallBack” 
parameter is a pointer to a “callback” function that will be executed when the “system 
breakpoint” is reached. 

If the function succeeds, the return value is TRUE. If the function fails, the return value is 
FALSE. 


bool stdcall DetachDebugger(DWORD Processld) 


We can't say much about the “DetachDebugger” function. It has an only parameter called 
“Processld” that is the PID (Process ID) of the process we want to dettach. This function 
sould be used when we use the “AttachDebugger” function to attach to a running process. 
If the function succeeds, the return value is TRUE. If the function fails, the return value is 
FALSE. 


void* stdcall GetProcessInformation() 


The “GetProcessInformation” function returns a pointer (or NULL if it fails) to a 
PROCESSJNFORMATION structure and it has no parameters. 


'oid* stdcall GetStartupInformation() 







The “GetStartupInformation” function does not receive parameters and it returns a pointer 
to a STARTUPINFO structure: 


typedef struct _STARTUPINFO { 


DWORD 

cb; 

LPTSTR 

IpReserved; 

LPTSTR 

lpDesktop; 

LPTSTR 

lpTitle; 

DWORD 

dwX; 

DWORD 

dwY; 

DWORD 

dwXSize; 

DWORD 

dwYSize; 

DWORD 

dwXCountChars; 

DWORD 

dwYCountChars; 

DWORD 

dwFi11Attribute; 

DWORD 

dwFlags; 

WORD 

wShowWindow; 

WORD 

cbReserved2; 

LPBYTE 

lpReserved2; 

HANDLE 

hStdlnput; 

HANDLE 

hStdOutput; 

HANDLE 

hStdError; 


} STARTUPINFO, *LPSTARTUPINFO; 


It is worth it to clarify that both “GetProcessInformation” and “GetStartupInformation” can 
only be called if a debug session is currently running. 


long long stdcall GetDebuggedDLLBaseAddress() 


The “GetDebuggedDLLBaseAdress” function does not receive parameters and it returns a 
long long value which is a pointer to the base address in which the DLL that is being 
debugged was loaded. This is a useful function because the DLLS, as you surely know, 
can be loaded in a different ImageBase than the one present in the PE PIEADER. For 
example, this is very common under Oses like Windows Vista, Windows 7 and Windows 
2008 where we have ASLR. 


long long stdcall GetDebuggedFileBaseAddress() 


The “GetDebuggedFileBaseAddress” is the counterpart of the 
“GetDebuggedDLLBaseAddress” function for executable files. It does not receive 
parameters and it returns a pointer to the base address where the executable image was 
loaded. 





'oid stdcall DebugLoopQ 


The “DebugLoop” function is responsible for starting the debugging session. It is the one 
that starts the loop between WaitForDebugEvent and ContinuDebugEvent. It is the heart 
and soul of a debugger and the responsible for handling all the debugging events. This 
function does not receive parameters and it must be called right after the “InitDebug” 
function. It is worth it to mention that we will return from a call to this function only when 
the debugging session ends. This function does not return a value. 


bool _stdcall StopDebug() 


The “StopDebug” does not receive parameters and is reposible for finishing the debugging 
session. Once we call this function, the control of the execution is passed to the first 
instruction right after the call to the “DebugLoop”. If the function succeeds, the return value 
is TRUE. If the function fails, the return value is FALSE. 


void stdcall ForceCloseO 


The “ForceClose” function does not receive parameters and, as its names implies, forces 
the termination of a debugging session in cases when the application crashes or when the 
program has an abnormal situation that it can't handle and finish in a normal state. This 
function does not return a value. 


bool _stdcall SetBPX(ULONG_PTR bpxAddress, DWORD bpxType, LPVOID 

bpxCallBack) 


The “SetBPX” function is used to set software breakpoints, the famous “\xcc” (INT3). As 
we can see, it receives various parameters: “bpxAddress” is the memory address in the 
debuggee where we want to set the breakpoint, “bpxType” a DWORD value, that can be 
any of the following values: 

• UEBREAKPOINT 

• UE_SINGLESHOOT 

• UE_BREAKPOINT_TYPE_INT3 (OxCC) 

• UE_BREAKPOINT_TYPE_LONG_INT3 (0xCD03) 

• UE_BREAKPOINT_TYPE_UD2 (OxOFOB) 

The last parameter is “bpxCallBack”. It must be a pointer to a “callback” function that will 
be triggered when the breakpoint is reached. If the function succeeds, the return value is 
TRUE. If the function fails, the return value is FALSE. 







bool stdcall EnableBPX(ULONG PTR bpxAddress) 


The “EnableBPX” function receives just one parameter, “bpxAddress”. It represents the 
address of the breakpoint we want to enable. 

If the function succeeds, the return value is TRUE. If the function fails, the return value is 
FALSE. 


bool stdcall DisableBPX(ULONG PTR bpxAddress) 


The “DisableBPX” function has only one parameter. It represents the address of the 
breakpoint we want to disable. 

If the function succeeds, the return value is TRUE. If the function fails, the return value is 
FALSE. 


bool _stdcall DeleteBPX(ULONG_PTR bpxAddress) 


The “DeleteBPX” function receives only the address of the breakpint we want to delete. 

If the function succeeds, the return value is TRUE. If the function fails, the retuen value is 
FALSE. 


bool stdcall SetMemoryBPX(ULONG PTR MemoryStart, DWORD SizeOfMemory, 
LPVOID bpxCallBack) _ 


The “SetMemoryBPX” function receives the “MemoryStart” parameter that is the memory 
address from which we want to set the memory breakpoint, “SizeOfMemory” is a DWORD 
value that indicates the size of the memory breakpoint, that is the range in which we want 
to set the breakpoint, and the “bpxCallBack” parameter is a pointer to a “callback” function 
that will be triggered when the memory breakpoint is reached. 

If the function succeeds, the return value is TRUE. If the function fails, the return value is 
FALSE. 


bool stdcall RemoveMemoryBPX(ULONG PTR MemoryStart, DWORD SizeOfMemory) 


The “RemoveMemoryBPX” function receives two parameters, “MemoryStart” indicates the 
address where the memory breakpoint starts and “SizeOfMemory” indicates the size of the 
memory breakpoint we want to remove. If the function succeeds, the return value is TRUE. 
If the function fails, the return value is FALSE. 







bool stdcall SetHardwareBreakPoint(ULONG PTR bpxAddress, DWORD 
IndexOfRegister, DWORD bpxType, DWORD bpxSize, LPVOID bpxCallBack) 


The SetHardwareBreakPoint function is used to set hardware breakpoints, as you 
probably guessed. For this, it receives “bpxAddress” that is the address where we want to 
set the breakpoint, “IndexOfRegister” tells the function the CPU register where we want to 
store the breakpoint (remember that we have from DRO to DR3, if none register is 
declared, then the first free register will be used to store the memory address), “bpxType” 
indicates the type of hardware breakpoint we want to set and it can be 
UE_HARDWARE_EXECUTE to set a hardware breakpoint on execution, 
UE_HARDWARE_WRITE to set a hardware breakpoint on write or 

UE_HARDWARE_READWRITE to set a hardware breakpoint on read/write. The “bpxSize” 
parameter can be UE_HARDWARE_SIZE_1, UE_HARDWARE_SIZE_2 o 
UE_HARDWARE_SIZE_4 and indicates the size in bytes that will be affected by the 
hardware breakpoint. Last but not least, we have the “bpxCallBack” parameter that is a 
pointer to a “callback” function that will be executed after the hardware breakpoint is 
reached. 

If the function succeeds, the return value is TRUE. If the function fails, the return value is 
FALSE. 


bool stdcall DeleteHardwareBreakPoint(DWORD IndexOfRegister) 


The “DeleteHardwareBreakPoint” function receives the “IndexOfRegister” parameter to 
indicate the number of register where the breakpoint we want to delete is. If the function 
succeeds, the return value is TRUE. If the function fails, the return value is FALSE. 


bool _stdcall RemoveAllBreakPoints(DWORD RemoveOption) 


The “RemoveAllBreakPoints” function erase or disable all the breakpoints specified by the 
“RemoveOption” parameter. These can be: 

• UE_OPTION_REMOVEALL (removes all the breakpoints) 

• UE_OPTION_DISABLEDALL (disables all the breakpoints, software and hardware 
breakpoints) 

• UE_OPTION_REMOVEALLDISABLED (removes all the disabled software 
breakpoints) 

• UE_OPTION_REMOVEALLENABLED (removes all the enabled software 
breakpoints) 


If the function succeedds, the return value is TRUE. If the function fails, the return value is 
FALSE. 





long long stdcall GetContextData(DWORD IndexOfRegister) 


The “GetContextData” function is used to read information of the current context thread. It 
receives the “IndexOfRegister” that indicates the register from where we want to retrieve 
information, for example, UE_EAX. 

If we want to obtain information from another thread, we should use “GetContextDataEx”: 


long long stdcall GetContextDataEx(HANDLE hActiveThread, DWORD 
IndexOfRegister) 


This function receives an extra parameter, “hActiveThread”, this is a HANDLE value of the 
thread from which we want to obtain information. 

On the other side, we have“SetContextData” and “SetContextDataEx”: 


bool stdcall SetContextData(DWORD IndexOfRegister, ULONG PTR 
NewRegisterValue) 


bool _stdcall SetContextDataEx(HANDLE hActiveThread, DWORD 

IndexOfRegister, ULONG PTR NewRegisterValue) _ 


Both functions are used to set the register we indicate in the “IndexOfRegister” parameter. 
The only difference between these functions is that “SetContextData” does its job in the 
context of the current thread and “SetContextDataEx” receives an extra parameter called 
“hActiveThread” that indicates the thread from which we want to obtain the information. 

Both functions return TRUE if they are successful and FALSE if they fail. 


long long stdcall Find(LPVOID MemoryStart, DWORD MemorySize, LPVOID 
SearchPattern, DWORD PatternSize, LPBYTE Wildcard) 


long long stdcall FindEx(HANDLE hProcess, LPVOID MemoryStart, DWORD 
MemorySize, LPVOID SearchPattern, DWORD PatternSize, LPBYTE Wildcard) 


The “Find” and “FindEx” functions are used to search for patterns in the context of the 
debuggee. The “FindEx” function receives the “hProcess” parameter that indicates the 
process in which we want to search. As you can imagine, both functions receives a pointer 
called “MemoryStart” that is the address to start the search. The “MemorySize” parameter 
indicates the size of the memory region we want to search, “SearchPattern” is a pointer to 
the binary pattern we want to search in the process and “PatternSize” is the size of the 
pattern. Finally, the “Wildcard” parameter is a pointer to a byte used as wildcard in the 
pattern, this byte will be ignored and considered always as found. If the function succeeds, 








the return value is a pointer to the memory address where the first byte of the pattern was 
found. If the function fails, the return value is NULL. 


bool _stdcall HideDebugger(HANDLE hProcess, DWORD PatchAPILevel) 


The “HideDebugger” function hides our debugger (TE) from many well known anti¬ 
debugger tricks like lsDebuggerPresent.lt receives a HANDLE value “hProcess” that is a 
handle to the process we want to hide. Then, a DWORD value “PatchAPILevel” that 
indicates which API functions are going to be patched to hide the debugger. In general, 
you will always use UE_HIDE_DEBUGGER that hides your debugger from: GetTickCount 
and CheckRemoteDebuggerPresent. If the function succeeds, the return value is TRUE. If 
the function fails, the return value is FALSE. 


bool stdcall UnHideDebugger(HANDLE hProcess, DWORD PatchAPILevel) 


The “UnHideDebugger” function restore the state of “HideDebugger”. It receives an 
“hProcess” to indicate the process we want to work with and the “PatchAPILevel” 
parameter indicates which API call are going to be restored. If the function succeeds, the 
return value is TRUE. If the function fails, the return value is FALSE. 


Long long stdcall GetJumpDestination(HANDLE hProcess, ULONG_PTR 
InstructionAddress) 


The “GetJumpDestination” receives an “hProcess” that is a handle to the process we want 
to work with and it returns the memory address of where a JMP instruction goes to. We 
can use the “InstructionAddress” parameter to tell the function the address where the JMP 
is. If the “InstructionAddress” parameter is used with something that is not the address of a 
JMP or a CALL, then, the function returns NULL. 


bool stdcall IsJumpGoingToExecute() 


The “IsJumpGoingToExecute” function only returns TRUE or FALSE if the current JMP is 
going to be taken (if is going to JMP or not) or not. 






void* stdcall GetPEBLocation(HANDLE hProcess) 


The “GetPEBLocation” function only receives a parameter called “hProcess” that is a 
handle to a given process and it returns a pointer to the PEB (Process Environment 
Block). If the function fails, the return value is NULL. 


'oid _stdcall SetCustomHandler(DWORD Exceptionld, LPVOID CallBack) 


The “SetCustomHandler” function allows us to set a custom exception handler. The 
“Exceptionld” parameter is the type of exception we want to handle (you can search the 
values in the TE documentation because it is an extensive list, or you can take a look at 
the stdafx.h file from the TE source code) and the “CallBack” parameter is a pointer to a 
function that will be executed when the exception occurs. 

The “callback” function must be defined in the following way: 


typedef void( stdcall *cbCustomHandler)(void* ExceptionData); 


Well, up to here with the “Debugger Module” functions. 

Without doubts, this is the more complete and the one with more function module in the 
SDK. As i said before, the modules we are going to use the most are the Debugger, 
Dumper and the Importer and because this tutorial is not pretended to be the official TE 
documentation, we are going to see just the most important functions of those modules. 

For those who probably want more information about the functions included in every of 
these modules, please, read the official documentation of TE. 

• Pumper's Module Functions 

The following are the functions we are going to see: 

• DumpProcess and DumpProcessEx 

• DumpMemory and DumpMemoryEx 

• DumpRegions and DumpRegionsEx 

• DumpModule and DumpModuleEx 

• PastePEHeader 

• FindOverlay 

• CopyOverlay 

• AddOverlay 

• MarkAIISectionsRWE 

• AddNewSection and AddNewSectionEx 

• GetPE32Data and GetPE32DataEx 

• SetPE32Data and SetPE32DataEx 







GetPE32DataFromMappedFile and GetPE32DataFromMappedFileEx 
SetPE32DataForMappedFile and SetPE32DataForMappedFileEx 




bool stdcall DumpProcess(HANDLE hProcess, LPVOID ImageBase, char* 
szDumpFileName, ULONG PTR EntryPoint) _ 


bool stdcall DumpProcessEx(DWORD Processld, LPVOID ImageBase, char* 
szDumpFileName, ULONG PTR EntryPoint) _ 


Both “DumpProcess” and “DumpProcessEx” are used to dump the whole memory region 
of a given process in a given point. 

The file generated by these functions is a binary representation of the memory region, it is 
not a valid PE file, it's a state of memory at the time the function is called. 

These two functions has a main difference which is the first parameter, the “DumpProcess” 
function receives a PIANDLE value indicating the process we want to use to dump memory 
from and “DumpProcessEx” receives a PID (Process ID). 

Also, they receive the “ImageBase” parameter that is a pointer to the ImageBase of the 
process we want to dump (this value must be read from the file on disk), 
“szDumpFileName” is a pointer to a string with the name we want for the file with the 
content of the dumped memory, “EntryPoint” is a VirtualAddress that will be used in the file 
as EntryPoint. 

If the function succeeds, the return value is TRUE. If the function fails, the return value is 
FALSE. 


bool stdcall DumpMemory(HANDLE hProcess, LPVOID MemoryStart, ULONG PTR 
MemorySize, char* szDumpFileName) 


bool stdcall DumpMemoryEx(DWORD Processld, LPVOID MemoryStart, 
ULONG PTR MemorySize, char* szDumpFileName) _ 


The “DumpMemory” and “DumpMemoryEx” functions, unlike the “DumpProcess” and 
“DumpProcessEx”, are used to dump memory regions of a given process. They receive 
“MemoryStart” that is the memory address we are going to use as start, “MemorySize” in 
the size of the memory region we want to dump and “szDumpFileName” is a pointer to a 
string with the file name we want to use for the file that will be created by the function. 

Also, the first parameter of “DumpMemory” is the handle of the process we want to work 
with and “DumpMemoryEx” receives the PID (Processld) of the process we want to work 
with instead of a process handle. 






If the function succeeds, the return value is TRUE. If the funciton fails, the return value is 
FALSE. 


bool stdcall DumpRegions(HANDLE hProcess, char* szDumpFolder, bool 
DumpAbovelmageBaseOnly) 


bool stdcall DumpRegionsEx(DWORD Processld, char* szDumpFolder, bool 
DumpAbovelmageBaseOnly) 


The “DumpRegions” and “DumpRegionsEx” function are used to dump all the regions of 
memory we indicate for a process.(The first parameter will be a FIANDLE for 
“DumpRegions” and a PID for “DumpRegionsEx”). Every region will be dumped in a 
separate file in a folder of our choice. Also, they receive another two parameters: 
“szDumpFolder” is a pointer to a string containing the name of the folder in which we want 
to store the dumped files and “DumpAbovelmageBaseOnly” is a flag we can use to 
indicate if the memory regions to dump will be lower or greater than the ImageBase of the 
process. If the function succeeds, the return value is TRUE. If the function fails, the return 
value is FALSE. 


bool stdcall DumpModule(HANDLE hProcess, LPVOID ModuleBase, char* 
szDumpFileName) 


bool stdcall DumpModuleEx(DWORD Processld, LPVOID ModuleBase, char* 
szDumpFileName) 


Both “DumpModule” and “DumpModuleEx” receive a HANDLE or a PID, respectively, a 
“ModuleBase” parameter that is the base address of the module to dump and 
“szDumpFileName” is the name of the file in which the information will be stored. 

These functions allow us to dump a whole module (for example, a DLL). If the function 
succeeds, the return value is TRUE. If the function fails, the return value is FALSE. 


bool stdcall PastePEHeader(HANDLE hProcess, LPVOID ImageBase, char* 
3 zDebuggedFileName) 


The “PastePEHeader” function would be useful to copy the PE Header from a file on disk 
to the memory of a process of our choice. This is very, very useful when we deal with 
packers that destroy the values of the PE Header loaded in memory before jumping to the 
OEP. 

The first parameter for this function is “hProcess” a HANDLE of the process we want to 
copy the PE Header to. The “ImageBase” is the image base address of the file we will 
copy the PE Header to, and, finally, “szDebuggedFileName” is the name of the file we 







want to take the PE Header from. If we are programming an unpacker, this file will be the 
one we are debugging. 

If the function succeeds, the return value is TRUE. If the function fails, the return value is 
FALSE. 


bool stdcall FindOverlay(char* szFileName, LPDWORD OverlayStart, 
LPDWORD OverlaySize) 


The “FindOverlay” function is responsible for searching overlay data (extra data appended 
to the file) in an executable file. 

The first parameter is “szFileName” and is the name of the file in which we want to search 
for overlay data, also, it receives two pointers, the first one is “OverlayStart” and this will be 
the variable that will receive the memory address when the overlay data starts and 
“OverlaySize” is a variable that will receive the size of the overlay data found by the 
function. If the function succeeds, the return value is TRUE. If the function fails, the return 
value is FALSE. 


bool _stdcall CopyOverlay(char* szInFileName, char* szOutFileName) 


The “CopyOverlay” function is responsible for copying the overlay data appended to the 
end of the file to another file. It receives two arguments: the “szInFileName” parameter is 
input file we want to extract the overlay data from and the “szOutFileName” indicates the 
file that will receive the extracted data. If the function succeeds, the return value is TRUE. 
If the function fails, the return value is FALSE. 


bool stdcall AddOverlay(char* szFileName, char* szOverlayFileName) 


The “AddOverlay” function is very similar to “CopyOverlay” but “CopyOverlay” can be used 
only with executable files. 

Instead, the “AddOverlay” can be used with non-executable files. 

The “szFileName” parameter is the name of the file we want to extract the data from and 
the “szOverlayFileName” parameter is the name of the file we want to append the data to. 
If the function succeeds, the return value is TRUE. If the function fails, the return value is 
FALSE. 


bool stdcall MakeAllSectionsRWE(char* szFileName) 


The “MakeAllSectionsRWE” function does exactly what its name implies, it makes all the 
sections from an executable readables, writeables and executables and it has just one 
parameter “szFileName”, this is the name of the executable file we want to work with. If the 






function succeeds, the return value is TRUE. If the function fails, the return value is 
FALSE. 


long stdcall AddNewSection(char* szFileName, char* szSectionName, DWORD 
SectionSize) 


The “AddNewSection” function creates a new section in an executable file filled with null 
bytes. The “szFileName” parameter is the name of the file we want to add a section to, 
“szSectionName” is the name we want to use for the new section and “SectionSize” is the 
size we want to assign to the new section. If the function succeeds, the return value is the 
relative virtual offset of the newly created section. If the function fails, the return value is 
NULL. 


long stdcall AddNewSectionEx(char* szFileName, char* szSectionName, 
DWORD SectionSize, DWORD SectionAttributes, LPVOID SectionContent, DWORD 
ContentSize) 


The “AddNewSectionEx” function does the same task than the “AddNewSection” function, 
it receives the same first three parameters but it has the extra “SectionAttributes” 
parameter that is a DWORD indicating the section's new attributes. These attributes are 
the ones defined in the PECOFF. If we do not assign any value to this parameter the 
default value will be RWE (0xE0000020). If the function succeeds, the return value is the 
relative virtual offset of the newly created section. If the function fails, the return value is 
NULL. 


long long stdcall GetPE32Data(char* szFileName, DWORD WhichSection, 
DWORD WhichData) 


The “GetPE32Data” function is responsible for giving us the values of the PE Pleader from 
the file we request (both PE and PE+). Its parameters are: “szFileName” is the name of the 
file we want to get info from, “WhichSection” is the section number (starting from 0) in 
which the data we want is present and “WhichData” is a constant value indicating the type 
of data we want, for example, UEJMAGEBASE (to know all possible values, please, read 
the TE documentation). This function returns the PE Pleader data. 


bool _stdcall GetPE32DataEx(char* szFileName, LPVOID Datastorage) 


This function, “GetPE32DataEx”, is very similar to the GetPE32Data, it receives the 
“szFileName” parameter to indicate the name of the file we want to obtaing information 
from and “Datastorage”. This parameter is a pointer to a structure defined inside TE and 
it's different for x86 and x64 files. This structure has lot information related to the PE 
structure, as we can see: 






typedef struct{ 

DWORD PE320ffset; 

DWORD ImageBase; 

DWORD OriginalEntryPoint; 
DWORD NtSizeOfImage; 

DWORD NtSizeOfHeaders; 

WORD SizeOfOptionalHeaders; 
DWORD FileAlignment; 

DWORD SectionAligment; 

DWORD ImportTableAddress; 
DWORD ImportTableSize; 

DWORD ResourceTableAddress; 
DWORD ResourceTableSize; 

DWORD ExportTableAddress; 
DWORD ExportTableSize; 

DWORD TLSTableAddress; 

DWORD TLSTableSize; 

DWORD RelocationTableAddress; 
DWORD RelocationTableSize; 
DWORD TimeDateStamp; 

WORD SectionNumber; 

DWORD Checksum; 

WORD Subsystem; 

WORD Characteristics; 

DWORD NumberOfRvaAndSizes; 

}PE32Struct, *PPE32Struct; _ 


And for 64 bits files would be the following: 


typedef struct{ 

DWORD PE640ffset; 

DWORD64 ImageBase; 

DWORD OriginalEntryPoint; 
DWORD NtSizeOfImage; 

DWORD NtSizeOfHeaders; 

WORD SizeOfOptionalHeaders; 
DWORD FileAlignment; 

DWORD SectionAligment; 

DWORD ImportTableAddress; 
DWORD ImportTableSize; 

DWORD ResourceTableAddress; 
DWORD ResourceTableSize; 

DWORD ExportTableAddress; 
DWORD ExportTableSize; 

DWORD TLSTableAddress; 

DWORD TLSTableSize; 

DWORD RelocationTableAddress; 
DWORD RelocationTableSize; 
DWORD TimeDateStamp; 

WORD SectionNumber; 

DWORD Checksum; 

WORD Subsystem; 

WORD Characteristics; 

DWORD NumberOfRvaAndSizes; 

}PE64Struct, *PPE64Struct; _ 





If the function succeeds, the return value is TRUE. If the function fails, the return value is 
FALSE. 


bool stdcall SetPE32Data(char* szFileName, DWORD WhichSection, DWORD 
WhichData, ULONG PTR NewDataValue) 


The “SetPE32Data” function is the counterpart of “GetPE32Data”. This function allows to 
set specific data in an executable file we can indicate in the “szFileName” parameter. The 
“WhichSection” parameter indicates the section number (starting from 0) where we want to 
set the data, with “WhichData” we indicate the type of data to set, for example, 

UE_IM AGE BASE. The last but not least is the “NewDataValue” parameter that is the value 
to set. If the function succeeds, the return value is TRUE. If the function fails, the return 
value is FALE. 


bool _stdcall SetPE32DataEx(char* szFileName, LPVOID Datastorage) 


The “SetPE32DataEx” is very similar to the one mentioned before, is has the “szFileName” 
parameter that is the name of the executable file we want to set the data and 
“Datastorage” that is a pointer to a defined structure in TE (different for x86 and x64) in 
which we indicate the data we want to set to the executable file. This structure is the same 
we saw some pages ago, PE32Struct y PE64Struct, and you can fill it with a call to the 
“GetPE32DataFromMappedFileEx” function or you can fill it by hand, field by field. If the 
function succeeds, the return value is TRUE. If the function fails, the return value is 
FALSE. 


long long stdcall GetPE32DataFromMappedFile(ULONG PTR FileMapVA, DWORD 
WhichSection, DWORD WhichData) 


The “GetPE32DataFromMappedFile” function is used with files that were loaded by the 
“StaticLoad” function. The “StaticLoad” function belongs to the Static module and allows to 
work statically with files, like if we were debugging them. It receives the “FileMapVA” that 
is the VirtualAddress of the content from the file in memory, “WhichSection” receives the 
number of sections (starting from 0) from which we want to obtain information and in 
“WhichData” we indicate a constant value that is the type of data we want to read, for 
example, UE_SECTIONFLAGS. If the function succeeds, it returns the requested value. If 
the function fails, the return value is 0. 


bool _stdcall GetPE32DataFromMappedFileEx(ULONG^PTR FileMapVA, LPVOID 

Datastorage) 


The “GetPE32DataFromMappedFileEx” is very similar to the 

“GetPE32DataFromMappedFile” function, it receives as first parameter “FileMapVA” that is 
a VirtualAddress where we have the file mapping. The second parameter is “Datastorage” 
that is a pointer to a PE32Struct or PE64Struct structure which we are going to fill with our 






data. If the function succeeds, the return value is TRUE. If the function fails, the return 
value is FALSE. 


bool _stdcall SetPE32DataForMappedFile(ULONG_PTR FileMapVA, DWORD 

WhichSection, DWORD WhichData, ULONG PTR NewDataValue) 


The “SetPE32DataForMappedFile” is the counterpart of the 

“GetPE32DataFromMappedFile” function. This function allows us to fill the region where 
we have a file mapping. It receives the “FileMapVA” parameter that is the address where 
the file mapping starts, “WichSection” is a constant number (starting from 0) indicating the 
section where we want to put the information, “WhichData” is a constant number that 
indicates the type of data we want to set, for example, UE_SECTIONFLAGS and 
“NewDataValue” is the value we want to use. If the function succeeds, the return value is 
TRUE. If the function fails, the return value is FALSE. 


Bool _stdcall SetPE32DataForMappedFileEx(ULONG_PTR FileMapVA, LPVOID 

Datastorage) 


The “SetPE32DataForMappedFileEx” is the counterpart of the 
“GetPE32DataFromMappedFileEx” function. This function receives “FileMapVA” (the 
memory address where the file mapping starts) and “Datastorage” (a PE32Struct o 
PE64Struct structure). It allows us to set specific data in the file mapping. If the function 
succeeds, the return value is TRUE. If the function fails, the return value is FALSE. 

• Realigner's Module Functions 


These are the the functions we are going to talk about: 

• RealignPE and RealignPEEx 

• IsFileDLL 

• lsPE32FileValidEx 


long _stdcall RealignPE(ULONG^PTR FileMapVA, DWORD FileSize, DWORD 

RealingMode) 


The “RealignPE” is responsible for realigning the PE. Specifically, it fixes the sections with 
the correct values (VirtualSize, RawSize, VirtualAddress and RawAddress). It receives the 
“FileMapVA” parameter that is the address (VirtualAddress) where the file mapping begins, 
“FileSize” is the size of the file mapping and finally, “RealignMode” is a reserved variable 
that must be always NULL (it is reserved for a future use in TE). If the function succeeds, 
the return value is the size of the realigned file. If the functions fails, the return value is 
NULL. 






long stdcall RealignPEEx(char* szFileName, DWORD RealingFileSize, DWORD 
ForcedFileAlignment) 


The “RealignPEEx” function does exactly the same job as “RealignPE” but instead of 
doing over a memory region with the file mapping it does it on a file on disk. In the 
“szFileName” we must specify the name of the file to work with, in “RealignFileSize” we 
must define the size of the file we want once the file is realigned, this parameter must be 
used only if we want to increase the file size, otherwise, it must be always 0. Finally, 
“ForcedFileAlignment” is a value used for “FileAlignment”, if we do not set this parameter, 
the default value is 0x200. If the function succeeds, the return value is the size of the 
realigned file. If the function fails, the return value is NULL. 


bool stdcall IsFileDLL(char* szFileName, ULONG PTR FileMapVA) 


The “IsFileDLL” function returns TRUE if the file specified in the “szFileName” is a DLL. 
Otherwise, it returns FALSE. Also, we can use the “FileMapVA” parameter instead of the 
“szFileName” to specify the VirtualAddress of the file mapping. 


Bool stdcall IsPE32FileValidEx(char* szFileName, DWORD CheckDepth, 
LPVOIdT FileStatusInfo) 


The “lsPE32FileValidEx” performs checks on files to decide if the file is a PE or a PE+. 
The “szFileName” parameter is the path to the file we want to work with.With 
“CheckDepth” we specify the depth we want use for the analysis. It has two possible 
values, UE DEPTH SURFACE or UE DEPTH DEEP. 

Finally, “FileStatusInfo” is a pointer to a FILE_STATUS_INFO structure. This structure will 
be filled by a call to this function (this parameter can be NULL). If the function succeeds, 
the return value is TRUE. If the function fails, the return value is FALSE. 


typedef struct{ 

BYTE OveralEvaluation; 

bool EvaluationTerminatedByException; 

bool FileIs64Bit; 

bool FileIsDLL; 

bool FilelsConsole; 

bool MissingDependencies; 

bool MissingDeclaredAPIs; 

BYTE SignatureMZ; 

BYTE SignaturePE; 

BYTE EntryPoint; 

BYTE ImageBase; 

BYTE SizeOflmage; 

BYTE FileAlignment; 

BYTE SectionAlignment; 

BYTE ExportTable; 

BYTE RelocationTable; 

BYTE ImportTable; 






BYTE ImportTableSection; 

BYTE ImportTableData; 

BYTE IATTable; 

BYTE TLSTable; 

BYTE LoadConfigTable; 

BYTE BoundlmportTable; 

BYTE COMHeaderTable; 

BYTE ResourceTable; 

BYTE ResourceData; 

BYTE SectionTable; 

)FILE_STATUS_INFO, *PFILE_STATUSJNFO; 


• Importer's Module functions 

This is one of the most important modules and one that we will use more. Its main 
functionality is to handle all the stuff related to the Import Table. Some of its main functions 
are the following: 

• Importerlnit 

• ImporterAddNewDII 

• ImporterAddNewAPI 

• ImporterAddNewOrdinalAPI 

• ImporterEstimatedSize 

• ImporterCleanup 

• ImporterExportlAT 

• ImporterAutoFixIAT and ImporterAutoFixIATEx 

• ImporterAutoSearchlAT and ImporterAutoSearchlATEx 

void stdcall Importerlnit(DWORD MemorySize, ULONG PTR ImageBase) _ 


This function is responsible for preparing the needed variables for the engine to work as it 
must. The only parameters that it receives are “MemorySize” that indicates how much 
memory the importer will need to store all the neccessary information for each DLL that is 
added to the importer. In general terms, no more than 40 kb are needed (as the 
documentation says). The “ImageBase” indicates the image base of the executable file. 


r oid stdcall ImporterAddNewDII(char* szDLLName, ULONG PTR FirstThunk) 


The “ImporterAddNewDII” function is the responsible for adding a new entry in the DLLs 
tree. After a call to this function is performed we must invoke the function to add the 
imported functions the DLL has. Once all the functions were added we must invoke this 
function once again to continue adding more functions from another DLL. 







This function receives the “szDIIName” parameter that is a pointer to the name of the DLL 
we want to add. Optionally, in the “FirstThunk” parameter we can indicate a pointer to the 
memory address of the first imported function we are going to add to the current entry. If 
this parameter is NULL, we can invoke the “ImporterAddNewAPI” directly to add the 
function to the entry. 


void stdcall ImporterAddNewAPI(char* szAPIName, ULONG PTR ThunkValue) 


The “ImporterAddNewAPI” function is used to add imported functions from the DLL we 
indicated with the “ImporterAddNewDII” function. This function receives the “szApiName” 
parameter that is a pointer to a string with the name of the imported function we are going 
to add and “ThunkValue” is a pointer to the address of the function we want to add. 


void stdcall ImporterAddNewOrdinalAPI(ULONG PTR OrdinalNumber, 
ULONG^PTR ThunkValue) 


The “ImporterAddrNewOrdinalAPI” does the same as “ImporterAddNewAPI”, ergo, adds a 
function to the current entry but intead of using a pointer to the name of the function as first 
parameter we use the OrdinalNumber of the function. It is very useful when we deal with 
functions imported by ordinal instead of name. 


long stdcall ImporterEstimatedSize() 


The “ImporterEstimatedSize” returns a value close to the necessary size needed to store 
all the information required by the importer. This function is very useful to determine the 
size of the section that will hold the new IAT. 


r oid stdcall ImporterCleanup() 


The “ImporterCleanup” is used to clean up all the stored information in the importer. It 
deletes all the DLLs and functions leaving a cleaning importer. This function must be 
invoked once the unpacking process finished or when the new fixed IAT was added to the 
executable file. 


bool _stdcall ImporterExportlAT(ULONG_PTR StorePlace, ULONG_PTR 

FileMapVA) _ 


The “ImporterExportlAT” is the one that is really going to take off the information from the 
importer module and going to store it where we indicate in the “StorePlace” parameter. 

The first parameter is the physical address in the file where we are going to store the 
newly import table. The “FileMapVA” parameter is a pointer to the information we are 
going to add, ergo, the import table. If the function succeeds, the return value is TRUE. If 
the function fails, the return value is FALSE. 
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long stdcall ImporterAutoFixIAT(HANDLE hProcess, char* szDumpedFile, 
ULONG PTR ImageBase, ULONG PTR SearchStart, DWORD SearchSize, DWORD 
SearchStep) 


We can use the “ImporterAutoFixIAT” function to try to automatically fix all the IAT 
redirections. To do its job, it uses the following parameters: “hProcess” is a handle to the 
process we want to work with, “szDumpedFile” is a pointer to a string indicating the name 
of the dumped file with the non fixed IAT and where we later are going to add the newly 
IAT the function returns. The “ImageBase” indicates the Image Base of the executable file 
we are working with. The “SearchStart” parameter is the address from where we want to 
start to search the needed information to the fixes. This parameter can be easily found by 
invoking the “ImporterAutoSearchlAT” function.. The “SearchSize” indicates the size (in 
bytes) of the memory region in which we are going to search the pointers to the imported 
functions. Finally, the “SearchStep” is used to iterate over the position we are searching, 
generally, this is always NULL. 


long stdcall ImporterAutoFixIATEx(HANDLE hProcess, char* szDumpedFile, 
char* szSectionName, bool DumpRunningProcess, bool RealignFile, ULONG PTR 
EntryPointAddress, ULONG PTR ImageBase, ULONG PTR SearchStart, DWORD 
SearchSize, DWORD SearchStep, bool TryAutoFix, bool FixEliminations, 
LPVOID UnknownPointerFixCallback) 


The “ImporterAutoFixIATEx” does the same job as “ImporterAutoFixIAT” with the only 
difference that we can indicate some other parameters to do a more specific job. 

For example, the “DumpRunningProcess” can be True or False to indicate if the file was 
previously dumped or not. Likewise, the “RealignFile” can be True or False to indicate if 
the resultant file must be realigned or not once the imports are added. 

In the “EntryPointAddress” we can indicate the EP address we want to store in the 
dumped file. 

The “TryAutoFix” is a bool value (generally, this value is always True) indicates that the 
IAT must be fixed, but, only in the case we were working with an executable file that does 
not have IAT redirection we could do without it and set it in False. 

The “FixEliminations” is always True to indicate that deleted entries by the packer must be 
fixed but if we do not have an executable with IAT redirection, we can set this value to 
False. 

Finally, “UnknownPointersFixCallback” can be used to specify a callback function in which 
we can try to fix import table redirection that the engine can't handle itself. 

The callback function must be declared in the following way: 




typedef void*( stdcall *fFixerCallback)(LPVOID flATPointer); 


Something important is that both functions return the following errors: 

• NULL - Critical error! *just to be safe, but it should never happen 

• 0x400 - Success 

• 0x401 - Error, process terminated 

• 0x404 - Error, memory could not be read 

• 0x405 - Error, no API found 

• 0x406 - Success, but realign failed 


void stdcall ImporterAutoSearchlAT(HANDLE hProcess, char* szFileName, 
ULONG^PTR ImageBase, ULONG_PTR SearchStart, DWORD SearchSize, LPVOID 
pIATStart, LPVOID pIATSize) _ 


The “ImporterAutoSearchlAT” is used to search an address that could be used to indicate 
a possible import table inside the executable file, rather, the process we are working with, 
this is why it receives the “hProcess”, a handle to the process. 

The “szFileName” indicates the name of the executable file for the handle we use and this 
file is used to search the import table. 

The “ImageBase” is the Image Base of the executable file we are working with. 

The “SearchStart” parameter is the start address from which to search the import table. 

The “SearchSize” parameter is the size (in bytes) of the memory region indicated in the 
“SearchStart” parameter. 

The “pIATStart” parameter is going to receive the address where the import table was 
found and the “pIATSize” parameter is used to store the size of the found import table. 


void stdcall ImporterAutoSearchlATEx(HANDLE hProcess, ULONG_PTR 
ImageBase, ULONG_PTR SearchStart, DWORD SearchSize, LPVOID pIATStart, 
LPVOID pIATSize) _ 


The “ImporterAutoSearchlATEx” function does the same job as “ImporterAutoSearchlAT' 
except that this function does not use the “szFileName” parameter. 





Relocater Module 




The Relocater module is going to be used in cases where we are working with DLLs 
because we surely will need to fix the relocation table. 

Some of the most important functions of this module are: 

• Relocaterlnit 

• RelocaterCleanup 

• RelocaterAddNewRelocation 

• RelocaterExtimatedSize 

• RelocaterMakeSnapshot 

• RelocaterCompareTwoSnapshots 


void stdcall Relocaterlnit(DWORD MemorySize, ULONG_PTR OldlmageBase, 
ULONG PTR NewImageBase) _ 


The “Relocaterlnit” function is used to initialize the relocater module. This function must be 
used before any other function belonging to the relocater module. 


r oid stdcall RelocaterCleanup () 


The “RelocaterCleanup” is used to clean up all the information stored in the relocater 
module. This function must be invoked once all the relocations have been fixed or when 
the unpacking process finished. 


void stdcall RelocaterAddNewRelocation(HANDLE hProcess, ULONG_PTR 
RelocateAddress, DWORD RelocateState) 


The “RelocaterAddNewRelocation” is used to add entries that correspond to addresses 
that need to be rebased if the file is allocated in a different address than the default. 

It receives the “hProcess” that is a handle to the process we want to work with. 

The “RelocateAddress” parameter indicates the address that needs to be rebased. 

The “RelocateState” parameter must be always NULL because it is reserved for future use 
in the SDK. 


Long stdcall RelocaterEstimatedSize() 


The “RelocaterEstimatedSize” does an approximation of the size needed to, later, write the 
relocation table in the newly created file. 








In general terms, this function is used to decide the approximate size the new section 
(.reloc) will have. 


bool stdcall RelocaterMakeSnapshot(HANDLE hProcess, char* 
szSaveFileName, LPVOID MemoryStart, ULONG PTR MemorySize) 


The “RelocaterMakeSnapshot” function is useful for taking snapshots, ergo, to dump 
memory from a process to disk at one point in time. It is like taking a picture of the memory 
state. 

This is extremely useful, for example, when we want to create the relocation table because 
we can dump the memory state when the unpacking process starts and once again once 
the process finishes its execution. So, we have two memory states (one at the beginning 
and one at the end) of the process and we can use this to create the relocation table. 

It receives the “hProcess” that is a handle to the process we want to work with. 

The “szSaveFileName” parameter is the name of the file we want to use for the snapshot 
file. 

The “MemoryStart” and “MemorySize” parameters will have the start and the size, 
respectively, of the memory region we want to dump. 

If the function succeeds, the return value is TRUE. If the function fails, the return value is 
FALSE. 


bool _stdcall RelocaterCompareTwoSnapshots(HANDLE hProcess, ULONG_PTR 

LoadedlmageBase, ULONG PTR NtSizeOfImage, char* szDumpFilel, char* 
;zDumpFile2, ULONG PTR^MemStart) _ 


The “RelocaterCompareTwoSnapshots” function is used to create the relocation table by 
comparing two memory snapshots. 

It receives the “hProcess” parameter that is a handle to the process we want to work with. 

The “LoadedlmageBase” indicates the Image Base where the file was loaded. 

The “NtSizeOflmage” indicates the SizeOflmage of the file loaded in memory. 

The “szDumpFilel” and “szDumpFile2” parameters are pointers to strings containing the 
name of the snapshot files. 

Finally, the “MemStart” is a pointer to a memory region inside the process we used as start 
point for the snapshot. 

If the function succeeds, the return value is TRUE. If the funciont fails, the return value is 
FALSE. 




Static Module 




The static module will provide functions to work statically with a file. Unlike other modules, 
this module was created to work with crypters (and similars to it) in a static way (not 
dynamic) because sometimes, we don't need to execute (or debug) a process to unpack it. 

The most important functions from this module are the following: 

• StaticFileOpen 

• StaticFileClose 

• StaticFileLoad 

• StaticFileUnload 

• StaticMemoryDecrypt 

• StaticMemoryDecompress 


bool stdcall StaticFileOpen(char* szFileName, DWORD DesiredAccess, 
LPHANDDE FileHandle, LPDWORD FileSizeLow, LPDWORD FileSizeHigh) _ 


The “StaticFileOpen” just returns a handle in the “FileFlandle” parameter to the file we 
indicated in the “szFileName” parameter. 

This function is just a wrapper for CreateFile and like this function in the “DesiredAccess” 
parameter we can indicate the type of desired access we want to have for the file, like 
GENERIC_READ and/or GENERIC_WRITE. 

The “FileSizeLow” receives the size (in bytes) of the open file like the “FileSizeHigh” 
parameter. The latter must be used when work with files larger than 4 GB. 

If the function succeeds, the return value is TRUE. If the funciont fails, the return value is 
FALSE. 


void stdcall StaticFileClose(HANDLE FileHandle) 


The “StaticFileClose” function just closes the handle used as argument in the FileHandle 
parameter. 


bool stdcall StaticFileLoad(char* szFileName, DWORD DesiredAccess, bool 
SimulateLoad, LPHANDLE FileHandle, LPDWORD LoadedSize, LPHANDLE FileMap, 
PULONG PTR FileMapVA) _ 


The “StaticFileLoad” is used to map the file in memory. 

It is a wrapper for “CreateFileMapping” and “MapViewOfFile”. 







The parameters we should use are “szFileName” that is a pointer to the name of the file 
we want to map, “DesiredAccess” indicates the type of access we want for the mapping 
file and can be: 

• UEACCESSREAD 

• UEACCESSWRITE 

• UEACCESSALL 

Later, the “SimulateLoad” is a bool in which we can set TRUE or FALSE to indicate if we 
want a simulation of the Windows PE Loader (the OS routine responsible for loading an 
executable file in memory). 

The “LoadedSize” receives the size of the mapped file. 

The “FileMap” parameter receives a handle to the mapped region. 

The “FileMapVA” parameter receives the base address of the mapped region. 

If the function succeeds, the return value is TRUE. If the function fails, the return value is 
FALSE. 


Bool stdcall StaticFileUnload(char* szFileName, bool CommitChanges, 
HANDLE FileHandle, DWORD LoadedSize, HANDLE FileMap, ULONG PTR FileMapVA) 


The “StaticFileUnload” function allows to unload a memory region mapped with 
StaticFileLoad. 

This function receives the “szFileName” indicating the name of the file that will receive the 
changes. 

The “CommitChanges” parameter indicates if the changes that were performed in the 
mapped region must be stored. 

The “FileHandle” must be filled with the handle returned by the “StaticFileLoad” function, 
as the “LoadedSize”, “FileMap” and “FileMapVA” parameters. 

If the function succeeds, the return value is TRUE. If the function fails, the return value is 
FALSE. 


void stdcall StaticMemoryDecrypt(LPVOID MemoryStart, DWORD MemorySize, 
DWORD DecryptionType, DWORD DecryptionKeySize, ULONG_PTR DecryptionKey) 


The “StaticMemoryDecrypt” function is used to decrypt an encrypted memory region that 
was encrypted with some simple algorithm like XOR 

For the function to work, we must indicate the “MemoryStart” parameter with the start of 
the memory region to decrypt. 




The “MemorySize” is the size of the encrypted memory region. 

The “DecryptionType” parameter indicates the type of algorithm that should be used to 
decrypt the memory region and can be one of the following values: 

• UE_STATIC_DECRYPTOR_XOR: If the memory region was encrypted using a 
XOR instruction. 

• UE_STATIC_DECRYPTOR_ADD: If the memory region was encrypted using an 
ADD instruction. 

• UE_STATIC_DECRYPTOR_SUB: If the memory region was encrypted using a 
SUB instruction. 

In the “DecryptionKeySize” parameter we indicate the size of key used to encrypt and can 
be one of the following values: 

• UESTATICKEYSIZEI 

• UESTATICK E Y_S IZ E_2 

• UE_STATIC_KEY_SIZE_4 

• UE_STATIC_KEY_SIZE_8 

Finally, the “DecryptionKey” is the key used to encrypt the memory region. 


Bool stdcall StaticMemoryDecompress(void* Source, DWORD SourceSize, 
r oid* Destination, DWORD DestinationSize, int Algorithm) 


The “StaticMemoryDecompress” function is used to decompress a memory region. 

In the “Source” and “SourceSize” parameters, it receives the start and size, repectively, of 
the memory region to decompress. 

The “Destination” and the “DestinationSize” parameters receive the address of the buffer 
and the size of that buffer, respectively, in which the decompressed data will be stored. 

Finally, in the “Algorithm” parameter we indicate the type of algorithm we want to use for 
the decompression. 

Can be one of the following values: 

• UESTATICAPLIB 

• UESTATICAPLIBDEPACK 

• UESTATICLZMA 

If the function succeeds, the return value is TRUE. If the function fails, the return value is 
FALSE 



OK, lets talk about different programs we could use over other programs to perform other 
tasks. 

A task could be to protect the executable file from prying eyes (like ours), to decrease the 
size of the file or even to “hide” the real content of the file. 

Any of these programs can work in a single layer or they can work together in many layers. 
It all depends on what each wants to achieve. I mean, for example, a packer with 
compression, encryption, etc; would have a single layer for compression and another layer 
for protection or in the case of a simple compressor with just a simple anti-dbg technique 
that would have just the compression layer. 

Lets see a brief description of any of these programs. 

a- Compressors 

A compressor is a program which main task is to compress (decrease) the size of 
another file. 

In this category, we can mention programs like UPX, Petite and FSG among 
others. 

From the point of view of the protection, a compressor is not considered a program 
to protect another program but to decrease its size. If a compressor had protection 
routines (anti-dbg, anti-dump, etc.) would stop being just a compressor and would 
add an overhead in the process' performance (the protected file would increase it 
size too and would take longer to load into memory). 

b- Crypters 

A crypter is a program used to “hide” the code of another program. 

With “hide” i mean to encrypt, through some algorithm, the original code of the 
program, adding obfuscation of different types to obstruct the analysis of the code. 

We may consider a crypter like a basic protection mechanism we could find in our 
race inside the unpacking as discipline. 

In general terms, crypters, besides the routine resposible for decrypting the code, 
will have a compression layer. This should not be but in most cases it is to 
decrease the file size of the encrypted file. 

c- Packers 

A packer, or a “protector” is, from my point of view, the more advanced type of 
program at the time for protecting another piece of program because, besides to 
include several compression layers, it also includes the necessary code to 
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obfuscate the program code (and the packer's code itself) while executing itself, a 
protection layer with a lot of tricks to difficult the analysis (like anti-dbg, anti-dumps, 
code redirection, IAT redirection), or today's trend, a VM with all the tricks 
mentioned before. 

Packers (as well as compressors and some crypters) append an extra section to 
the end of the executable with all the necessary code for the unpacking and 
decompression of every section included in the executable, as well as its their own 
layers of compressed code, anti-dbg tricks, anti-dumps, the necessary code to fix 
the IAT and finally, to jump to the OEP. 

I borrowed a little diagram from the TE documentation to show you in a graphical 
way the execution flow and the structure of a packer: 



Through TE we can automate tedious tasks like fixing the IAT, code redirection or anti- 
dbg/anti-dump tricks in an easily way. 
















5- Unpackers 


Finally, we are in the heart of this tutorial, from now on we are going to see the funniest 
part. Regrettably (or not) the above things were needed in order to understand a little bit 
more all how the things work. 

In this chapter, we are going to talk a little bit about unpackers, what are they?, how many 
kinds of them are they?what is the difference between them? All this questions will be 
answered. But first, lets answer the big question. 

a- What is an unpacker? 

An unpacker is a program that is used to, in an automatic way, remove a packer from a 
program 

To program an unpacker is not an easy task, it depends on the type of packer we want to 
remove. If we want to remove an easy packer, then, the unpacker will be easy too (or it 
should be), but, if what we want to unpack is the latest version of Themida, then, you have 
a big trouble. 

While using TE, we are going to solve some of the most tedious jobs in an easy way. For 
example, we are not going to have the need to program all the functions to dump a 
process, or validate an executable file, the need to know if a file is an EXE or a DLL, and 
so on. 

You can say: “Hey, but you can program all those functions just one time, to put them in a 
library and re-use them”. Yes, that is true but you need the necessary time to program all 
those functions, test the functions and fix the bugs :) 

TE, as any other computer program, has bugs. Guan de Dio and I reported some of them 
to the author, but, without doubts, the hard work is done. 

OK, now, inside the Unpackers category, we can see two types of unpackers, the dynamic 
unpackers and the static unpackers. Let's see a what is the difference between them. 

b- Dynamic unpackers, what are they and how they work? 

A dynamic unpacker is the most used type of unpacker because is one of the most easy to 
implement but we must be careful because the way they work is debugging the program 
we want to unpack (executing it), so, we have a risk because if we want to unpack a 
malware sample, we must do it in an isolated environment or to take the necessary cares 
to not infect our machine. 

Due to this, we must have the maximum control over the sample we are trying to unpack. 
How?, well, you can do as much as checks to be sure what it going on with the execution 
flow. 



c- Static unpackers, what are they and how they work? 

Static unpackers are also very easy to implement but the ease depends of the type of 
protection we are attacking. If we are dealing with just a crypter that encrypts the code 
section by a XOR and stores all the encrypted code in the same executable, then, is a 
piece of cake. The only thing we need to do is to revert the XOR operation and that's it. 

The static unpackers work in an opposite way to the dynamic unpackers, they do not have 
the need to execute the program. They examine the code in a static way, trying to find the 
key to decrypt the information (code, data). This kind of unpacker is widely used when we 
deal with crypters and compressors. 

d- Generic unpackers, what are they and how they work? 

These are, without doubts, the most harder to implement. A generic unpacker is the one 
who attacks any protected type of program (packer, compressor or crypter) and tries to 
remove the protection. The “generic” unpackers, and generic is in quotes because in fact, 
there is no generic unpacker that can deal with all the existing protections, are those that 
can deal with all those protection that have the same behaviour. 

To program a generic unpacker, we must design an algorithm capable of including that 
behaviour and deal with it. 

6- 1- Dynamic unpackers with TitanEnqine 

To program a dynamic unpacker using TE is a very simple task and does not requiere so 
much time, for easy packers like ASPack, tElock, etc; with harder packers it is a little more 
complex but we can design another type of tools to help in the unpacking process. For 
example, if we are trying to unpack an Armadillo, we can write a program that once stops 
at the OEP it can fix the nanomites or code splicing. 

To program an unpacker using TE, as we said, is an easy task and is a serie of steps (in 
most cases they are going to be always the same) that we are going to see in details when 
writing a FUU plugin. Anyways, these are the common steps used when programming an 
unpacker using TE: 

a- a- Load the executable and use the TE functions to get information from the file 
and validate it(GetPE32Data). 

b- Start the debugging session with the InitDebugO and DebugLoop() functions, 
c- We must set breakpoints in places that would be the key for the unpack process, 
for example, the place where the imported functions are solved, the place where 
the relocations are calculated, the places where the anti-debugger tricks are called, 
the places where the anti-dumps tricks are, etc; each of these BPXs will be 
handled by callback functions (a function that will be called when a BPX is 
triggered). 

d- We must program a specific function for every callback that will be called, 
e- Finally, we must call the StopDebugQ to stop the debugging sesion. 


I'll borrow, once again, a graph from the TE docs to show you something in an easy way 
the previous steps: 



Don't be scared!, you will have some highlighted functions that would be the mainstay of 
every of our plugins, so it's better to see them now to start learning from now on. This is 
the kick off to start a FUU plugin using TE! © 

Well, in this graph we have the whole process that we must go over to program a dynamic 
unpacker using TE. 

Now, I know that you are thinking: “Why dynamic unpackers?”. Let's answer that question! 


















a- a- Why dynamic unpackers? 

As we said before, these unpackers are the easiest to program (and funny, I think) but the 
main reason is that they represent the way we are used to work in the world of the 
unpacking (from my point of view). The first thing we do when we have a new packer to 
deal with is: 

1) Load it in Oily (or our favorite debugger). 

2) Find the OEP. 

3) Find the place where the imports are solved. 

4) Find the places for the anti-dbg and anti-dumps tricks. 

5) Dump the process from the OEP. 

6) Fix the imports, relocs, anti-dumps, etc. 

Flowever, this seemed to me the best way to start working with TE and FUU and in this 
way we can dive into the dark waters of the automating unpacking process. 

An important thing I want to mention is that we must know the way the packer we want to 
unpack works and to know how to do the unpacker process by hand because without that 
knowledge you will not know how to start. Therefore, what I usually do is to unpack the 
packer by hand and after that I know how the packer works, then, I start to program the 
unpacker. 

7- FUU - [Flaster fUlniversal fUlnpacker 

Let's talk a little bit about a tool I made when i knew TE for the first time. In the next pages, 
we are going to se how it was born, how this tool works, what we can do with it and how to 
contribute with it. 

a- What is FUU? 

FUU is just a GUI. The heart of FUU are the plugins. 

Every plugin is an unpacker (most of them are plugins but we have tools too) specifically 
designed for a packer and the main idea of FUU is to include plugins as many packers are 
around the net, that is the goal i have, i know that this task will not be easy but i hope to 
finally do it. 

That is the meaning i want to give to the “Universal” word. 

b- How FUU was conceived? 

FUU was born in a boring afternoon when dealing with TE. 

Suddenly, i had a full working plugin and i didn't know where to put it, so, so i did a quick 
GUI using RadASM and then, i thought: “why just one?”. Let's program someting useful to 
include a lot of tools and plugins to unpack in an automatic way most of the packers 
around. And that is the main story, FUU is the result ot that boring afternoon ©. 



c- What FUU is for? 


Well, i think this was answered before. FUU, as we said, has a few plugins (for now) to 
allow you to unpack in an easy way (automatic way) some well know protections. We want 
to give it some others tools to provide a full set of tools to deal with easy, medium and 
harder protections and to do it in an easy way. 

d- How to write a FUU plugin? 

To write a plugin for FUU, we will need to know some things. First thing is to know a little 
bit the TE SDK in order to act in every situation. We should know the main functions of the 
SDK, how to use it, in which case use which function. Second, you will need to know how 
the engine works, it is very easy, but anyways, we must know it. 

Also, we will need some tools. In my case, i use MASM+RadASM. I will show you how to 
write a plugin for FUU using TE+MASM+RadASM. I know that many of you prefer another 
language like C/C++, Python, Etc; but ASM was the language i met when i started to play 
with cracking, it's the language i use the most and the one that FUU is made of. 

Also, it's the language that will provide us with a high speed to unpack. 

I want to make clear that we can program any of these plugins using some other 
languages like C, C++, Delphi, LUA or Python, but in my case, i'll use ASM. 

The first thing we need to know is that FUU only exports two functions: 

• GetPluginName 

• DoUnpack 

To export a function from a DLL in ASM we must create a .def file and put the following 
lines: 


LIBRARY 

EXPORTS 

DoUnpack 

GetPluginName 


That lines means that both, the “DoUnpack” and “GetPluginName” functions are exported 
by the library. 

This is the “GetPluginName” function: 


GetPluginName proc 
comment ~ 

Function Name: GetPluginName 

Function Description: Returns the plugin's name 
Function Parameters: None 





mov eax, offset PluginName 
ret 

GetPluginName endp 


It only returns in EAX the name of the plugin, that we have defined in the .inc file as 
follows: 

PluginName db “Plugin Test”,0 
We have a plugin named “Plugin Test”. 

The “DoUnpack” function is what actually does the job and needs some parameters: 

• hMainDIg 

• szFname 

• IpOptionsArray 

• IpReserved 

• IpParam 

The parameter "hMainDIg" is the handle to the main window of the FUU GUI. The 
parameter "szFname" is the full path to the executable we want to unpack, 
"IpOptionsArray" is a pointer to an array of pointers. Each of these elements of the array 
points to a flag representing different options as RealignPE and CopyOverlay. The 
RealignPE flag tells the plugin whether or not to realign the resulting file from the unpack 
process, the other flag, CopyOverlay, indicates whether to search for additional 
information in the original file and copy it to the dumped file. The parameter "IpReserved" 
is just an ID to verify if it is a plugin for FUU or not and for the moment is "FUU1" finally 
"IpParam" is a pointer to a parameter list that we are not using for now. 

Ok, let’s see the most basic skeleton for a FUU plugin. 


.586 

.model flat, stdcall 
option casemaprnone 

include sample.inc 

. code 

LibMain proc hlnstDLL:DWORD, reason:DWORD, unusedrDWORD 

mov eax, TRUE 
ret 

LibMain endp 

GetPluginName proc 

mov eax, offset PluginName 
ret 





GetPluginName endp 

DoUnpack proc hMainDlg:DWORD, szFname:DWORD, lpOptionsArray:DWORD, 
IpReserved:DWORD, IpParam:DWORD 

ret 

DoUnpack endp 
End LibMain 


See that we also have another function: LibMain, but this is one that any Windows 
program must have, it is the main() of the library. 

Ok, Well, that's all that would be part of our Asm, now let's see our .inc file: 


include windows.inc 
include kernel32.inc 
include user32.inc 
include comdlg32.inc 
include TitanEngine.inc 

includelib comdlg32.1ib 
includelib kernel32.1ib 
includelib user32.1ib 
includelib TitanEngine x86.1ib 

. data 

PluginName db "Plugin Test",0 

my_msg db "Message",0 

my title db "Title",0 _ 


As we see, it just has the includes among which are the .lib and the .inc that TitanEngine 
SDK gives us to do the magic. I have placed those libraries in their respective folders 
whithin MASM installation folder. I have placed TitanEngine.inc in /masm32/include and 
TitanEngine.lib inside /masm32/lib. 

Also, I have added two more variables: “my_msg” and “my_title” and I have placed a call 
to MessageBoxA within the “DoUnpack” function, like this: 


DoUnpack proc hMainDlg:DWORD, szFname:DWORD, lpOptionsArray:DWORD, 
IpReserved:DWORD, IpParam:DWORD 

invoke MessageBox, hMainDlg, offset my_msg, offset my title, MB_OK 
ret 

DoUnpack endp 
end LibMain 









After assembling, I place the resulting DLL in the folder/FUU/bin/Plugins/x86, then I run 
fuu.exe and I look at the ListBox: 


AS Pack 2.x Unpacker 
BeRoExePacker vl .0 Unpacker 
FSG 2.0 Unpacker 
Plugin T est 


There we see it loaded into the list of FUU plugins. Now load any executable, select that 
plugin and press “Unpack”: 



There we have our first FUU plugin ?. 

OKI. Now, let's dive into how to create something more useful, an unpacker. I will be 
working with two packers, FSG and exeFog, to see some more functions. Needless to say 
that with just those two plugins that we will see we are not able to cover all the functions 
that the SDK offers but if you want see more you just have to look at the sources of other 
FUU plugins. 

























































About exeFog I have already posted something in my blog about how it works: 

http://crackinqlandia.bloqspot.com/2010/07/new-fuu-pluqin-deexefoq.html 

About FSG we are going to see little here, anyway, they are very simple packers. 

Ok, to avoid making this tutorial longer, we are going to look the important things about 
FSG (I will be working with the v2.0): 


OliyDfag - fsg v2-0.exe - [CPU - main thread, module fsg_v2_0] 


C File View Debug Plugins Options Window Help 
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00400154 
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00400164 
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There we can see the packer EP. The jump to the OEP, as more than one will know, is 
always performed by JMP [EBP + C]: 


004001C9 
00400ICO 
00400ICC 
004001CD 

95 

8B07 

40 

A 78 F3 
v 75 03 

- FF63 0C 

XCHG EOX,EBP 

MOU EOX,DWORD PTR DS:CEDI] 

INC EOX 

JS SHORT fsg_v2_0.004001C2 

JNZ SHORT fsg_v2_0.004001D4 


JMP DWORD PTR DS:CEBX+C] 

fsg_u2_0.00401000 

004001D4 

50 

PUSH EOX 


004001D5 

55 

PUSH EBP 


004001D6 

FFS3 14 

COLL DWORD PTR DS:CEBX+14] 


004001D9 

OB 

STOS DWORD PTR ES:CEDI] 


00400IDO 

A EB EE 

JMP SHORT fsq_'v’2_0.00400ICO 


004001DC 

33C9 

XOR ECX.ECX 


00400 IDE 

41 

INC ECX 


00400IDF 

FF13 

COLL DWORD PTR DS:CEBX] 


004001E1 

13C9 

ODC ECX,ECX 



And the APIS from the IAT are solved in this place: 


004001BF 
004001 Cl 
004001C2 
004001C3 
004001C4 

•' EB 9F 

5E 

OD 

97 

OD 

50 

JMP SHORT fsg_w2_0.00400160 

POP ESI 

LODS DWORD PTR DS:CESI] 

XCHG EOX,EDI 

LODS DWORD PTR DS:CESI] 

PUSH EOX 



FF53 10 

COLL DWORD PTR DS:CEBX+10] 

Llama a LoadLibraryO 

004001C9 

95 

XCHG EOX,EBP 


00400ICO 

8B07 

MOU EOX,DWORD PTR DS:CEDI] 


00400 ICC 

40 

INC EOX 


004001CD 

- 78 F3 

JS SHORT fsg_M2_0.004001C2 


004001CF 

V 75 03 

JNZ SHORT fsgL^2_0.004001D4 


00400 ID 1 

FF63 0C 

JMP DWORD PTR DS:CEBX+C] 


004001D4 

50 

PUSH EOX 



55 

PUSH EBP 



FF53 14 

COLL DWORD PTR OS:CEBX+14] 

Llama a GetProcOddress 


OB 

STOS DWORD PTR ES:CEDI] 


00400 IDO 

~ EB EE 

JMP SHORT fsgLM2_0.00400ICO 


004001DC 

33C9 

XOR ECX.ECX 


00400 IDE 

41 

INC ECX 


00400 IDF 

FF13 

COLL DWORD PTR DS:CEBX] 


004001El 

13C9 

ODC ECX.ECX 


004001E3 

FF13 

COLL DWORD PTR DS:CEBX] 


004001ES 

- 72 F8 

JB SHORT Fs9_v2_0.00400IDF 


004001E7 

C3 

RETN 


004001F8 

o?n? 

onn m .m 

























The important thing is locating all these areas. In these cases it's simple because there is 
not IAT destruction, no stolen bytes, no code splicing or anything like that. But the general 
idea will always be the same: using patterns to locate the places where all these tasks are 
performed, i.e. we already know that the jump to the OEP is made by an indirect JMP and 
the IAT reconstruction is performed through two indirects CALLs. Now, what is the next 
step? Once we have already identified all the important areas, we must understand that 
each important area will be represented by a callback, for example, we first defined a 
callback to find patterns of all these important areas. In turn, we will have a callback 
defined for each of these important areas. Let’s see it: 

Well, the first thing we’ll do is to define a new function called “_DoUnpack”. This is a 
function that gets almost the same parameters than “DoUnpack” except by a tiny detail: 


DoUnpack proc hMainDlg:DWORD, szPathFileName:DWORD, dwCallBack:DWORD, 
IpReserved:DWORD, IpParam:DWORD 

ret 

DoUnpack endp 


As you can see, this function receives a parameter that was not in “DoUnpack” and this is 
“dwCallBack”. This parameter is a callback function that will be the first one running when 
we’ll start the debugging session. As we already said, the first thing we should do is to 
identify important areas in any way, so let’s do this first running function be the 
responsible of finding those patterns and tell us their addresses, it’s going to set a BPX in 
each important area and define a callback for each one of those too. 

But before, we must do some things like verify that the file is a valid executable and also 
take some data from the executable that we will need later. 

It is worth mentioning that in "DoUnpack" what we do is taking the parameters and get a 
handle to the ListBox of the FUU GUI, but I did not mentioned it here for not screwing you 
up, I want to concentrate on the most important things. What you should really have in 
mind is: from the "DoUnpack" section I'll call "_DoUnpack" passing in the parameter 
"dwCallBack" the cbFindPatterns function, which will be the first instance we use to find 
patterns of significant areas: 


invoke DoUnpack, hMainDlg, szFname, cbFindPatterns, IpReserved, IpParam 


Also worth mentioning that none of the functions defined as callbacks take parameters (a 
callback which can not receive parameters is not quite right, but we have already told the 
author of TE to consider it as an aggregate for the next version). 

To set a callback, just do the following: 


cbFindPatterns PROTO 






Let’s back to “_Dollnpack” and see which are those prior checks at the moment of starting 
a debugging session: 


mov eax, szPathFileName 

.if eax != NULL && byte ptr[eax] != NULL 


First of all, we verify that both the pointer to the path of the file to unpack and the first byte 
of the name are not NULL. 


invoke IsPE32FileValidEx, szPathFileName, UE_DEPTH_DEEP, NULL 
.if eax == 1 

invoke IsFileDLL, szPathFileName, NULL 
.if eax == NULL 

invoke GetPE32Data,szPathFileName,NULL,UE_IMAGEBASE 
mov dwImageBase,eax 

invoke GetPE32Data,szPathFileName,NULL,UE_OEP 
mov dwEntryPoint,eax 

invoke GetPE32Data,szPathFileName,NULL,UE^SIZEOFIMAGE 
mov dwSizeOfImage,eax 

invoke InitDebug, szPathFileName, NULL, NULL 


There we can see that first of all, we use the "lsPE32FileValidEx" to verify that the 
executable file is a valid PE. Following that, we check to see if the executable is a DLL (in 
this case because we do not want DLLs). Well, if it is a executable file, we repeatedly call 
the "GetPE32Data" to capture data such as the ImageBase, EntryPoint and the 
SizeOflmage that will be useful later. Finall, we call the “InitDebug” function to start the 
debugging session. 

As InitDebug returns a pointer to the structure PROCESSJNFORMATION with 
information about the process we began to debug, we do the following: 


mov ebx, eax 

mov eax, dwCallBack 

mov cblnitCallBack, eax 

invoke RtlMoveMemory, addr Processlnfo, ebx, sizeof PROCESS_INFORMATION 
invoke SetCustomHandler,UE_CH_CREATEPROCESS,addr cbGetEP 
invoke DebugLoop 


I move the pointer to PROCESSJNFORMATION to EBX, then, I keep the callback 
address into another variable, I copy PROCESSJNFORMATION content to a global 
variable, then using "SetCustomPlandler" set a callback to cbGetEP and finally start the 
debug loop calling DebugLoop. 
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The callback before cbFindPatterns I'm setting up is to get the address where the 
executable is loaded. Also we could have done this with "GetDebuggedFileBaseAddress". 


cbGetEP proc piPtr:DWORD 
pushad 

mov eax, piPtr 

assume eax:ptr CREATE_PROCESS_DEBUG_INFO 

mov ebx, dword ptr[eax].lpBaseOfImage 
mov dwLoadedBaseAddress, ebx 
assume eax:nothing 

mov ebx, dwLoadedBaseAddress 
add ebx, dwEntryPoint 

invoke SetBPX, ebx, UE_BREAKPOINT, cblnitCallBack 
invoke Importerlnit, 80 * 1024, dwLoadedBaseAddress 

popad 

ret 

cbGetEP endp 


As you can see, first of all, I move to EAX the PFtOCESSJNFORMATION pointer and 
then I get the field IpBaseOflmage from that structure and place it in EBX for later save it 
into the dwLoadedBaseAddress variable. Then I add the value stored in dwEntryPoint 
EntryPoint. Finally, I put a software breakpoint in the direction of Entry Point and passed the 
callback which was initially intended. Before leaving the function, we call the Importerlnit 
function to initialize the Importer module. As size, we pass 80 kb which is more than 
enough to contain all the information the SDK needs (default is 40 kb). 

Now let’s see the cbFindPatterns function. 

First at all we have this: 


mov esi, dwLoadedBaseAddress 
add esi, dwEntryPoint 
mov NoLog, 0 



invoke VirtualQueryEx, dword ptr[Processlnfo.hProcess] , 
Memlnfo, sizeof MEMORY BASIC INFORMATION 
mov edi, dword ptr[Memlnfo.BaseAddress] 
add edi, dword ptr[Memlnfo.RegionSize] 

esi. 

addr 

invoke VirtualQueryEx, dword ptr [Processlnfo.hProcess], 
Memlnfo, sizeof MEMORY BASIC INFORMATION 
add edi, dword ptr[Memlnfo.RegionSize] 
sub edi, esi 

edi. 

addr 





First of all, we move to ESI the direction in which the executable was loaded and we add 
the EP. Then, both calls to VirtualQueryEx are to get the size of the section which we will 
look for patterns (.code). 

Once we have the size of the region in which we will look for patterns, we start with all 
calls to the "Find" function: 


invoke Find, esi, edi, addr OEPPattern, OEPPatternSize, addr Wildcard 
.if eax != NULL 

mov ebx, eax 
add ebx, 4 

mov OEPPatternBPX, ebx 

invoke SetBPX, ebx, UE BREAKPOINT, OriginalEntryPointCB 

. else 

inc NoLog 

invoke LogMessage, addr PossibleNotPackedError 
invoke LogMessage, addr EndUnpackMsg 
invoke StopDebug 

.endif 


In this first call, we are going to find the pattern that correspond to the jump to the OEP, for 
this we use the “Find” function passing by EDI and ESI address and size from the zone 
which we will perform search, respectively. In addition, we pass it a pointer to the pattern, 
the pattern size and a pointer to the byte that we’re going to use as a wildcard, which in 
this case is 0. 


OEPPattern db 078h, OOOh, 075h, OOOh, OFFh, 063h, OOCh 
OEPPatternSize dd 7 
OEPPatternBPX dd 0 

OEPPatternCallBack dd offset OriginalEntryPointCB 


As you can see, the bytes pattern that we pass it, correspond to these instructions: 


004001CD 

A \78 F3 

JS 

SHORT fsg v2 0 

.004001C2 

004001CF 

75 03 

JNZ 

SHORT fsg v2 

0.004001D4 

004001D1 

FF63 0C 

JMP 

DWORD PTR DS: 

[EBX+C] 


I have highlighted the bytes that we will not consider in the search because they are 
offsets used in each jump and as we know, can vary. I just let the opcodes of the 
instructions. 

If the "Find" function finds the pattern we told it, it will return us a pointer to the area where 
the first byte of this pattern is found, then, what we do is taking that direction and add 4 to 
stay pointed at JMP DWORD PTR: [EBX + C] and that's where we use the "SetBPX" and 
pass the address of our callback defined for when the just set BPX, is reached. 

As you may have seen, I have defined the callback as follows: 


OEPPatternCallBack dd offset OriginalEntryPointCB 





And outside the .data section I have placed the callback header: 


OriginalEntryPointCB PROTO 


And the function is like any other function: 


OriginalEntryPointCB proc 
ret 

OriginalEntryPointCB endp 


Later we'll see what to write in it. 

Well, what I did to get the OEP pattern, is the same I'll do to get the LoadLibraryA and 
GetProcAddress pattern that is where packer resolves the imported DLL names and the 
imported functions addresses of these DLLs, respectively. 


invoke Find, esi, edi, addr LoadLibraryPattern, LoadLibraryPatternSize, 
addr Wildcard 
.if eax != NULL 

mov ebx, eax 
add ebx, 1 

mov LoadLibraryPatternBPX, ebx 

invoke SetBPX, ebx, UE_BREAKPOINT, LoadLibraryCB 

. else 

.if NoLog == 0 

invoke LogMessage, addr PossibleNotPackedError 
invoke LogMessage, addr EndUnpackMsg 
invoke StopDebug 
.endif 

.endif 


In the case of the pattern for LoadLibraryA is: 


LoadLibraryPattern db 050h, OFFh, 053h, OlOh 
LoadLibraryPatternSize dd 4 
LoadLibraryPatternBPX dd 0 

LoadLibraryCallBack dd offset LoadLibraryCB 


In this case, the pattern is consistent with the following instructions: 


004001C5 

50 

PUSH 

EAX 

004001C6 

FF53 10 

CALL 

DWORD PTR DS:[EBX+10] 


The callback for LoadLibraryA is defined exactly as for the OEP: 






LoadLibraryCallBack dd offset LoadLibraryCB 


If you notice, once we have the address of LoadLibraryA pattern, we add 1 to address in 
order to set the breakpoint on the CALL and not on the PUSH. 

Finally, we search for GetProcAddress pattern: 


invoke Find, esi, edi, addr GetProcAddressPattern, 
GetProcAddressPatternSize, addr Wildcard 
.if eax != NULL 

mov ebx, eax 
add ebx, 1 

mov GetProcAddressPatternBPX, ebx 

invoke SetBPX, ebx, UE_BREAKPOINT, GetProcAddressCB 

. else 

.if NoLog == 0 

invoke LogMessage, addr PossibleNotPackedError 
invoke LogMessage, addr EndUnpackMsg 
invoke StopDebug 

. endif 

.endif 


Here is exactly the same as in the other two cases, except for the pattern we are 
searching and the value we add to the address that "Find" give us. The pattern is as 
follows: 


GetProcAddressPattern db 055h, OFFh, 053h, 014h 
GetProcAddressPatternSize dd 4 
GetProcAddressPatternBPX dd 0 

GetProcAddressCallBack dd offset GetProcAddressCB 


This pattern is consistent with the following instructions: 


004001D5 

55 

PUSH 

EBP 

004001D6 

FF53 14 

CALL 

DWORD PTR DS:[EBX+14] 


Well, until now we have well-defined areas in which we will work. 

Common sense tells us that the first thing that will happen is that the LoadLibaryA callback 
will be the first to run for the simple reason that before jumping to the OEP it has to solve 
the functions that the program uses and to solve the functions the program uses it first 
needs to know which libraries are used which all makes sense. 

Let’s see now the callback for LoadLibraryA: 


LOCAL Memlnfo: MEMORY_BASIC_INFORMATION 
LOCAL NumberOfBytes: DWORD 

pushad 
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xor esi, esi 

invoke GetContextData, UE EIP 
.if eax == LoadLibraryPatternBPX 

invoke GetContextData, UE EAX 
mov esi, eax 

.endif 


First of all, we declare a few variables that we will use, then set ESI to 0 and using the 
"GetContextData" function we read the EIP in which we find ourselves standing in the 
debugged program, then, if the address “GetContextData” returns corresponds to the 
direction in which we place the BPX, we call “GetContextData” again, but this time to ask 
for EAX. At the moment of BPX, EAX will be pointing to the string with the name of the 
DLL: 


Registers (FPU) _ 

EflX 0040930A ASCII "KERNEL32.dll” 
ECX 00000000 
EDX 00000004 

EBX 00413398 fsg_y2_0.00413398 
ESP 0012FF88 
EBP 00000001 

ESI 004090P4 fsg_v2_0.004090P4 
EDI 00409014 PsgLw2_0.00409014 

EIP 004001C6 fsgLv2_0.004001C6 


Ok, that is the address we later place in ESI. 


.if esi > dwLoadedBaseAddress 

invoke VirtualQueryEx, dword ptr[Processlnfo.hProcess], esi, addr 
Memlnfo, sizeof MEMORY_BASIC_INFORMATION 

mov edi, dword ptr[Memlnfo.BaseAddress] 
add edi, dword ptr[Memlnfo.RegionSize] 

invoke VirtualQueryEx, dword ptr[Processlnfo.hProcess] , edi, addr 
Memlnfo, sizeof MEMORY_BASIC_INFORMATION 

add edi, dword ptr[Memlnfo.RegionSize] 
sub edi, esi 

.if edi > 256 

mov edi, 256 
.endif 

invoke ReadProcessMemory, dword ptr[Processlnfo.hProcess], esi, 
addr StringData, edi, addr NumberOfBytes 


Next, check that the ESI address is above the address where the executable was loaded, 
we do this to make sure it is reading addresses belonging to the header or other section 
above the image of the executable. If this condition is true, we use VirtualQuery calls to get 
the size of the section from which is getting the string and as you can see, the size must 
be less than 256 since it is the maximum size of our variable "StringData" which is where 
we will store the string. Actually we could have saved ourselves all that if we had used, for 
example, the "GetRemoteString" function from the "Debugger" module.Escuchar 







It is worth mentioning that some of these things are made this way because they are 
based on the first version of TE, in which many functions were not implemented yet. 

Well, then, passing the maximum size of string and the address from which we are going 
to read, we use ReadProcessMemory to read the string for the name of the DLL. 

If the ReadProcessMemory function returns a value other than NULL then we add the DLL 
to the importer: 


invoke ImporterAddNewDll, addr StringData, NULL 


We just call the "ImporterAddNewDll" function passing as a parameter the address of the 
string we want to add. 

With that we had completed the task of probablemente "resolving the DLLs used by the 
program". Now, let's see how we resolve the imported functions. 

The process with the callback of GetProcAddress is very similar to LoadLibraryA, except 
that instead of using the "ImporterAddNewDll" function we will use "ImporterAddNewApi" 
having in mind that the functions can be imported by name or ordinal. 


LOCAL Memlnfo: MEMORY_BAS I CONFORMATION 
LOCAL NumberOfBytes: DWORD 

pushad 
xor esi, esi 

invoke GetContextData, UE EIP 
.if eax == GetProcAddressPatternBPX 
invoke GetContextData, UE EAX 
mov esi, eax 

invoke GetContextData, UE EDI 
mov ebx, eax 

.endif 


As we see, we first declare a few variables that we will use later and then we made the 
same comparison as we did in LoadLibraryA, also confirm that the EIP in which we stand 
is where we set the BPX. If we are where we want to be, we call the "GetContextData" 
function twice, first to take the pointer to the string with the name of the imported function 
from EAX and the second call is to take from EDI the place into the IAT where that function 
should go: 


Registers (FPU)_< 

EAX 00409202 ASCII "GetConmandLLneA” 

ECX 77039257 kerne 132.77039257 
EDX 002B0178 

EBX 00413398 Fsg_v2_0.00413398 
ESP 0012FF84 

EBP 77010000 kerne 132.77010000 
ESI 004090A4 fsg_v2_0.004090A4 
EDI 00409014 Fsg_w2_0.00409014 

EIP 004001D6 fsg_y2_0.004001D6 






Once we past that part, we turn back to the two calls to VirtualQuery to get the size of the 
section from which we are trying to read the string of the imported function: 


.if esi > dwLoadedBaseAddress 

invoke VirtualQueryEx, dword ptr[Processlnfo.hProcess], esi, addr 
Memlnfo, sizeof MEMORY_BASIC_INFORMATION 

mov edi, dword ptr[Memlnfo.BaseAddress] 
add edi, dword ptr[Memlnfo.RegionSize] 

invoke VirtualQueryEx, dword ptr[Processlnfo.hProcess], edi, addr 
Memlnfo, sizeof MEMORY_BASIC_INFORMATION 

add edi, dword ptr[Memlnfo.RegionSize] 
sub edi, esi 
.if edi > 256 

mov edi, 256 
.endif 

invoke ReadProcessMemory, dword ptr[Processlnfo.hProcess], esi, 
addr StringData, edi, addr NumberOfBytes 


In the event that with ReadProcessMemory we could read the remote string, we will call 
the "ImporterAddNewApi" function passing as parameters the pointer to the string with the 
name of the function and also the address from the IAT in which should be the pointer to 
the imported function. 

invoke ImporterAddNewAPI, addr StringData, ebx 


In the variable “StringData” we have the name of the imported function and in EBX the 
address of the IAT in which the pointer to this function should be imported. 

If this function is imported by ordinal, all that must be changed in the call to 
"ImporterAddNewApi" is the first parameter rather than a string will be the ordinal: 


invoke ImporterAddNewApi, esi, ebx 


In ESI I have the ordinal of the function and in EBX the IAT address in which should be the 
pointer to that ordinal. 

With that we would have solved one more step and we would deal with a case that would 
be the callback of the OEP. 

Before continuing I want to say that this example we're seeing is one of the most simple 
and applies to ASPack style packers but I hope you got the main idea so you can apply it 
to more complex packers/protectors/compressors/etc. 




With another programs we can use more or less functions but the basic functions will be 
always the ones mentioned here. 

Now, let’s continue with the study of the callback that corresponds to the OEP. 


invoke GetContextData, UE EBX 
lea esi, dword ptr[eax] 
add esi, 12 

invoke ReadProcessMemory, dword ptr[Processlnfo.hProcess], esi, addr 
UnpackedOEP, 4, addr NumberOfBytes 


As we put the BPX right in the JMP DWORD PTR DS: [EBX + C] and [EBX + C] is pointing 
to the OEP, then, what we do is to take the EBX value from the context of the application 
calling the "GetContextData" function and we add 12 (OxOC). Once we have the address in 
which the OEP address is stored, we use ReadProcessMemory to read the value: 


00400 ICC 
004001CD 

40 

* 78 F3 
v 75 03 

- FF63 0C 

INC EfiX 

JS'SHORT f sg_x2_0.004001C2 

JNZ SHORT Fsguv2_0.004001D4 


JMP DWORD PTR DS:CEBX+CD 

f sg_v2_0.00401000 

004001D4 

50 

PUSH EPX 


004001DS 

55 

PUSH EBP 


004001D6 

FF53 14 

CPLL DWORD PTR DS:[EBX+14I 

Liana a GetProcPddress 

004001D9 

PB 

STOS DWORD PTR ES:CEDII 


004001DP 

* EB EE 

JMP SHORT PsgL^2_0.004001CP 


R 0400 inn 

3.309 

XOR FOX.FOX 



Registers (FPU) _ 

EPX 00000000 

ECX 76ED5910 ntdl1.76ED5910 
EDX 00000000 

EBX 00413398 fsg_v2_0.00413398 
ESP 0012FF8C 

EBP 74290000 OFFSET C0MCTL32.#212 
ESI 004090C4 fsgu^2_0.004090C4 
EDI 00409004 Fsg_v2_0.00409004 
EIP 004001D1 fsg_w2_0.004001D1 



After that, the first thing we do is to take the PE Header of the original file and place it in 
the process we are debugging: 


invoke PastePEHeader, dword ptr[Processlnfo.hProcess], 
dwLoadedBaseAddress, addr PathFileName 


After that and some message logs, dumped the process using "DumpProcess" and 
passing as parameters the handle of the process we want to dump, the address in which it 
is loaded, the name of the executable that we will give and address of the OEP: 



















invoke DumpProcess, dword ptr[Processlnfo.hProcess], dwLoadedBaseAddress, 
addr UnpackedFileNameBuffer, UnpackedOEP 


After dumping, what we do is to end the debugging session using the "StopDebug" 
function. 


invoke StopDebug 


Then we call the "ImporterEstimatedSize" function to estimate the size of the section we 
will add to rebuild the import table: 

invoke ImporterEstimatedSize 


invoke AddNewSection, addr UnpackedFileNameBuffer, addr MySection, ebx 


We use “AddNewSection” to add a new section to the dumped executable. The first 
parameter is the full path to the executable to which we add the section, then there's the 
name we are going to give to this new section and finally, in EBX the size of this new 
section. 

After that, we map the dumped file in memory and using the "ImporterExportlAT" function 
we add the information containing all the imports to the dumped file. Once we finish calling 
"ImporterExportlAT" we should call the function "ImporterCleanup" to finish cleaning the 
engine all information related to the Imports. 


invoke ImporterExportlAT, ebx, FileMapVA 


The EBX register contains the physical offset of the file in which the new IAT will be 
located and FileMapVA is the address in which we have stored information about the IAT 
we are going to add. 

Then we have things like PE realign and find and add the overlay (if any): 


invoke RealignPE, FileMapVA, FileSize, 2 


In the parameter FileMapVA goes to the area where we have the information we want to 
realign, the FileSize is the size of this information and the last parameter is the 
FileAlignment. 


invoke MakeAllSectionsRWE, addr UnpackedFileNameBuffer 






Using "MakeAllSectionsRWE", passing the full path to the file, we give all the sections of 
the new executable write, read and execute permissions. 

And finally, what I commented about the overlay: 


invoke FindOverlay, addr TempBuffer, addr OverlayStart, addr OverlaySize 
.if eax == 1 

invoke CopyOverlay, addr TempBuffer, addr UnpackedFileNameBuffer 


With that we conclude the last step to fully unpacking FSG. 

Let's see a little more with the exeFog plugin. 

In this case, besides the three callbacks we saw here, the one which corresponds to the 
OEP, the LoadLibrary and the GetProcAddress ones, we have two more callbacks due to 
they are required to unpack. Those two extra callbacks are cbDecryptionLoop and 
cbHideDebuggerFromExeFog extras. I think the name of each callback identifies very well 
what they do but if they are not clear, I’ll tell you that exeFog does not have all the code 
that decrypts layer and solve the DLLs and functions to the eye, but first there is a loop 
that decrypts all that code and it has an anti-dbg trick (IsDebuggerPresent) before it 
resolves DLLs and Imports, as I’ve described here: 

http://crackinqlandia.bloqspot.com/2010/07/new-fuu-pluqin-deexefoq.html 

Actually what the cbDecryptionLoop do is to look for patterns of the OEP, LoadLibrary and 
GetProcAddress, the callback before that is cbFindPatterns which is actually looking for 
the first pattern of all, the loop that decrypts the code: 


LOCAL Memlnfo: MEMORY_BASIC_INFORMATION 
pushad 

mov esi, dwLoadedBaseAddress 
add esi, dwEntryPoint 

invoke VirtualQueryEx, dword ptr[Processlnfo.hProcess], esi, addr 
Memlnfo, sizeof MEMORY_BASIC_INFORMATION 
mov edi, dword ptr[Memlnfo.BaseAddress] 
add edi, dword ptr[Memlnfo.RegionSize] 

invoke VirtualQueryEx, dword ptr[Processlnfo.hProcess], edi, addr 
Memlnfo, sizeof MEMORY_BASIC_INFORMATION 
add edi, dword ptr[Memlnfo.RegionSize] 
sub edi, esi 

invoke Find, esi, edi, addr DecryptionLoopPattern, 
DecryptionLoopPatternSize, addr Wildcard 
.if eax != NULL 

mov ebx, eax 

add ebx, sizeof DecryptionLoopPattern 
mov DecryptionLoopPatternBPX, ebx 

invoke SetBPX, ebx, UE BREAKPOINT, cbDecryptionLoop 





invoke 

. else 

invoke 

invoke 

invoke 

. endif 


LogMessage, 

LogMessage, 

LogMessage, 

StopDebug 


addr DecryptLoopBpxSet 

addr NoDecryptionLoopFound 
addr EndUnpackMsg 


popad 

ret 


As you can see, the structure is the same as the rest of the callbacks, the only thing that 
changes is the pattern we seek: 


DecryptionLoopPattern db 0B9h, 0C8h, OOOh, OOOh, OOOh, OBOh, OOOh, 030h, 
004h, OOBh, 0 8Ah, 004h, OOBh, 0E2h, 0F8h 


This pattern corresponds to the following instructions: 


0046B321 

B9 C8030000 

MOV ECX,3C8 


0046B326 

BO 92 

MOV AL,92 


0046B328 

30040B 

XOR BYTE PTR 

DS:[EBX+ECX],AL 

0046B32B 

8A040B 

MOV AL,BYTE 

PTR DS:[EBX+ECX] 

0046B32E 

* E2 F8 

LOOPD SHORT 

UnPackMe.0046B328 


I have highlighted the bytes that we use as wild cards. 

Ok, once we reach this loop is when we start searching for the rest of the patterns and the 
next step is to put a BPX in the anti-dbg area, passing anti-dbg and continue the execution 
of the next callbacks. 

Well, so far with plugins. I tried to explain as best as possible and I hope you have 
understood. In case of remaining doubts, you know you can email me at anytime. 

For more information, see the SVN project and view the source of each of the plugins we 
saw here: http://code.qooqle.eom/p/fuu/source/browse/#svn/trunk/src/x86/Pluqins 

e- The future of FUU 

Well, there's plenty to do about it. FUU main idea is to have a framework that allows rapid 
development of unpackers and also automatically allowing both the identification and the 
process of unpacking in most packers known nowadays. Today we are still far from that 
ultimate goal but step by step with each release of FUU we approach it. 

If someone wants to collaborate with the project will be welcomed, the idea is that 
collaboration come from the community and particularly from users. 

We are currently working to bring stability and a better way to program, we want 100% 
usability, that's why we are making several changes to the interface and the plugins. In 
addition, we provide 32-bit and 64-bit versions. 






1- Appendix 


In this appendix we will see some things that I found very interesting to include. The ideas 
are not mine but from the people of RLabs but it thought to complete the tutorial with this 
would be of benefit to read it since it is an interesting approach when unpacking. 

First, let's see how to unpack using hooks, then we will see how we can unpack a whole 
group of binaries or libraries at once without having to be unpacking one at a time. After 
that we will see how to use Python interface to work with TE and finally something about 
dynamic instrumentation using a tool named PIN and that although it was not designed for 
unpacking we could easily use it in our unpacking tools. 

a- Unpacking with Hooks 

Well. This is not an idea of mine but it seemed a good idea to share with you. This comes 
from a post on the RLabs blog, more precisely this: 

http://bloq.reversinqlabs.com/2010/06/unpackinq-by-hookinq/ 

What is the idea? The idea, as it says in the post, is to mix the code of our very unpacker 
with the packer and remove protection while the same protection is working. It sounds a bit 
strange, tangled and complex, but it is not so much. Something to consider in this type of 
technique is that we must be careful in cases in which we apply it because for hooking we 
need to overwrite data in the victim program memory so if the packer has some kind of 
checksum or CRC then it will be a little complicated but it would be a matter of finding the 
routine that performs the check and hook that area too. 

The good part of this method is that we skip the anti-dbgs tricks very easily because we 
are not debugging the target?. 

In this case, we will work directly on the files that the .rar brings. You can download it from 
the post and then we will see some source code to see what functions from the TE hooks 
library uses. 

This example consists of two parts, a program and a dll. The DLL is who does all the work 
and all the program does is to inject the DLL into the process and run it before the EP of 
the packer to start running. 

Now, to debug this kind of unpackers, we will have to do the following: First of all, we open 
the packed program with Oily: 


OllyDbg - crackme.upx.exe - [CPU - main thread, module crackmej 


C File View Debug Plugins Options Window Help 


»|«|xj ►JilJ *U illill ^1] 


00408160 

S 60 

PUSHRD 

00408161 

. BE 00604000 

MOU ESI,crackne_.00406000 

00408166 

. 8DBE 00B0FFFI 

LEA EDI,DWORD PTR DS:CESI+FFFFB000] 

0040816C 

. 57 

PUSH EDI 

0040816D 

. 83CD FF 

OR EBP.FFFFFFFF 

00408170 

V EB 10 

•JMP SHORT crackne_.00408182 

00408172 

90 

NOP 

00408173 

90 

NOP 

00408174 

90 

NOP 

naans 17=: 

sn 

nop 













Now, we go to an free area into the executable and enter the following grafts: 


WT 

004082B7 

004082B8 

O04082B9 

00403206 

00408 

00 

00 

. 75 70 78 48 6F 6F 6 

00 

00 

DB 00 

DB 00 

0SCII "upxHooks.dl1’’,0 

DB 00 

DB 00 


00408, 

E8 00120376 

rUoH Cr3CK 

COLL kerne 132.LoadLibraryO 

HoL 11 u pr! nook s ■ □ l l 

00408202 

^ E9 89FEFFFF 

JMP crackne .<Modu leEntryPoint> 


00408207 

00 

DB 00 


00408208 

00 

DB 00 


004082D9 

00 

DB 00 



We change the EIP so that we can execute the call to LoadLibraryA and we can load the 
unpacker DLL. Once passed by the call to LoadLibraryA watch what happens with the 
program code: 






S File 

View Debug Plugins 

Options Window Help 


<J 

► | ||| i*:| *:| >:| 

■ | ■ | ^ »| 

yf^jJ jJ eJmJjJwJ hJ cJ / 

| K | B | r[.~1 S | ]=J^2J 



8B5F 04 

MOU EBX,DWORD PTR DS:[EDI+4I 


00408275 


8D8430 10850000 

LEO EOX,DWORD PTR DS:[EOX+ESI+8510] 


00408270 


01F3 

ODD EBX.ESI 


0040327E 


E9 7D8DE069 

JMP upxHooks.60211000 


00408283 


96 

DB 96 


00408284 


40 

DB 40 

CHOR ’L’ 

00403285 


85 

DB 85 


00408286 


00 

DB 00 


00403287 


00 

DB 00 


00403288 


95 

XCH6 EOX.EBP 


00403289 

> 

8007 

MOU OL.BYTE PTR DS:CEDI] 


004032SB 


47 

INC EDI 


00408280 


0800 

OR RL,0L 


0040828E 

A 

74 DC 

JE SHORT crackne .00408260 


00408290 


89F9 

MOU ECX.EDI 


00403292 


E9 D98DE069 

JMP upxHooks.60211070 


00408297 


FF96 50850000 

COLL DWORD PTR DS:[ESI+8550I 


0040829D 


0900 

OR EOX.EOX 


0040329F 

.V 

74 07 

JE SHORT crackne .00408208 


00408201 


8903 

MOU DWORD PTR DS:[EBX],EOX 


00408203 


8303 04 

ODD EBX,4 


00408206 

A 

EB El 

JMP SHORT crack rie .00408289 


00403208 

> 

FF96 54850000 

COLL DWORD PTR DS:[ESI+8554I 


004082OE 

> 

61 

POPRD 


004082OF 


E9 5C8EE069 

JMP upxHooks.60211110 


004082B4 


00 

DB 00 


004032B 5 


00 

DB 00 


004032B6 


00 

DB 00 


004032B7 


00 

DB 00 


004082B8 


00 

DB 00 


004082B9 


75 70 78 48 6F 6F 6 

OSCII "upxHooks. d U”, 0 


00403206 


00 

DB 00 


004O82C7 


00 

DB @0 


00408208 


68 B9824000 

PUSH crackne .004082B9 

rFLleMane = "upxHooks.dll M 

004082CD 


E8 00120376 

COLL kerne 132.LoadLibraryO 

tLoadL ibraryfi 


A 

-E9 89FEFFFF 

JMP crackne .<ModuleEntryPoint> 


004032D7 


00 

DB @0 


004032DS 


00 

DB 00 


004082D 9 

iwiinn'inn 


00 

nn 

DB 00 

nn nn 



You see, there are now three new unconditional JMP to a memory area corresponding to 
the DLL just injected. If you look carefully, the three jumps are: 

0040827E .- E9 7D8DE069 JMP upxHooks.6A211000 LoadLibraryA Hook 

00408292 .- E9 D98DE069 JMP upxHooks.6A211070 GetProcAddress Hook 

004082AF .- E9 5C8EE069 JMP upxHooks.6A211110 OEP JMP Hook 

Each of these indirect JMP would represent each of the callbacks we saw earlier when we 
programed the FUU plugin except that here we do not use BPXs but directly overwrite the 
packer code. Now, when the packed program starts running we will see what each of 
these routines to which point the JMPS will make, put a BPX on each one: 

















OllyDbg - crackme.upxexe - [CPI 

J - main thread, module upxHooks] 

C File 

View Debug Plugins 

Options Window Help 

&\ii\ _x] +]ll\ ^Jj *-J jJ^eJjhJjJ wj hJ_cJ^_kJ 


60 

PUSHflD 

60211001 
60211006 
6021100B 
6021100D 
60211012 
60211017 
60211010 
6021101F 

£noi i n'ZA 

03 EC6S2260 

68 00010000 

60 00 

68 10692260 

E8 29940000 

83C4 0C 

68 00010000 

68 10692260 
m crcowcn 

MOU DWORD RTR DS:C602268FC3,EOX 

PUSH 100 

PUSH 0 

PUSH upxHooks.60226910 

COLL upxHooks.60210440 

ODD ESP,0C 

PUSH 100 

PUSH upxHooks.60226910 
mciii cnv ni.inDn dtd no. 



OllyDbg - crackme.upxexe - [CPU - main thread, module upxHooks] 


[c| File View Debug Plugins 

a|jj|_xj »Jjj] *•]♦•] 


Options Window Help 

j| -»J| *jj l| e|m| tiwi hi cl / 



60 

PUSHOD 


893D FC68226Q 

MOU DWORD PTR DS:C602268FC],EDI 


60211077 

89ID 00692260 

MOU DWORD PTR DS:[60226900],EBX 


6021107D 

68 00010000 

PUSH 100 


60211082 

60 00 

PUSH 0 


60211084 

68 10692260 

PUSH upxHooks.60226910 


60211039 

E8 B2930000 

COLL upxHooks.60210440 


6021103E 

33C4 0C 

ODD ESP,0C 


60211091 

01 FC682260 

MOU EOX,DWORD PTR DS:C602268FCI 


60211096 

3B05 08692260 

CMP EOX,DWORD PTR DS:[602269083 

cr 

6021109C 

v 7E 36 

JLE SHORT upxHooks.602110D4 


6021109E 

68 00010000 

PUSH 100 


60211003 

68 10692260 

PUSH upxHooks.60226910 


60211008 

8B0D FC6S2260 

MOU ECX,DWORD PTR DS:C602268FCI 


602110OE 

51 

PUSH ECX 


18QF 

FF1R 88282280 

r.QI 1 niiinRn PTR flS: KfcKFRNFI 32.fipr.r.urTPr. 



OllyDbg - crackme.upxexe - [CPU - main thread, module upxHooks] 


|C| File View Debug Plugins Options Window Help 


&] <<]_*] jdijj ^jj _lJ_eJ mJjJ wj hJ_cJj^| 



55 

PUSH EBP 


8 BEC 

MOU EBP,ESP 

60211113 

83E4 F8 

OND ESP,FFFFFFF8 

60211116 

83EC 24 

SUB ESP,24 

60211119 

33C0 

XOR EOX,EOX 

602111 IB 

56 

PUSH ESI 

6021111C 

894424 18 

MOU DWORD PTR SS:CESP+18I,EOX 

60211120 

894424 1C 

MOU DWORD PTR SS:CESP+1CI,EOX 

60211124 

894424 20 

MOU DWORD PTR SS:[ESP+203,EOX 

60211128 

894424 24 

MOU DWORD PTR SS:CESP+24I,EOX 

6021112C 

894424 08 

MOU DWORD PTR SS:CESP+8],EOX 

60211130 

894424 0C 

MOU DWORD PTR SS:[ESP+C],EOX 

60211134 

894424 10 

MOU DWORD PTR SS:CESP+103,EOX 

60211138 

894424 14 

MOU DWORD PTR SS:CESP+14I,EOX 

6021113C 

8D4424 18 

LEO EOX,DWORD PTR SS:CESP+18] 

60211140 

50 

PUSH EOX 


Well, once we have set all the BPXs we press F9 (Run) and see what happens. 




























Oily Dbg - crackme.upx.exe - [CPU - main thread, module upxHooks] 


C1 File View Debug Plugins 

►]!]] *}J*j] 


Options Window Help 

j| ^l] L | E | M] T | W| H | C | / | K | B | r|TL[ S | j=J^|j?J 



60 

PUSH0D 



03 FC682260 

MOU DWORD PTR DS:C602268FC],EOX 


60211006 

68 00010000 

PUSH 100 


6021100B 

60 00 

PUSH 0 


6021100D 

68 18692260 

PUSH upxHooks.60226910 


60211012 

E8 29940000 

COLL upxHooks.60210440 


60211017 

83C4 0C 

ODD ESP,0C 


60211010 

68 00010000 

PUSH 100 


6021101F 

68 10692260 

PUSH upxHooks.60226910 


60211024 

01 FC68226Q 

MOU EOX,DWORD PTR DS:C602268FC3 


60211029 

50 

PUSH EOX 


60211020 

FF15 00202260 

COLL DWORD PTR DS:[C&KERNEL32.GetCurrentProcess>] 

k ern e 132.Get Cu rrent Process 

60211030 

50 

PUSH EOX 


60211031 

E8 F80C0100 

COLL <JMP.&TItanEngLne.GetRenoteStrLng> 


60211036 

0FB6C8 

MOUZX ECX,OL 


60211039 

85C9 

TEST ECX,ECX 


6021103B 

v 74 0C 

JE SHORT upxHooks.60211049 


6O21103D 

60 00 

PUSH 0 


6021103F 

68 10692260 

PUSH upxHooks.60226910 


60211044 

E8 EB0C0100 

COLL <JMP.&TitanEngine.IroporterOddNewDll > 


60211049 

(■ P yb tUSfe^^6n 

PUSH DWORD PTR DS:C602266EC3 

crackne .0040827E 

6021104F 

E8 E60C0100 

COLL <JMP.&TitanEng Lne.HooksGetTranpolLneOddress> 


60211054 

2D 63102160 

SUB EOX,upxHooks.60211063 


60211059 

83E8 05 

SUB EOX,5 


6021105C 

8905 64102160 

MOU DWORD PTR DS:[60211064],EOX 


60211062 

61 

POPOD 


60211063 

- E9 90909090 

JMP FOB1O0F8 


60211063 

CC 

INT3 


60211069 

CC 

INT3 



The first BPX stops here. As we can see, we have a very well known call to us, that is 
"ImporterAddNewDII" thus assume that this function is responsible for collecting all 
information about the DLLs that the program uses. In fact, let’s trace up to the 
"GetRemoteString": 


602110301 

602110361 
60211039| 


50 

PUSH EAX 

E8 F80C0100 

CALL < JMP.&TitanEngine.GetRercoteStr Lng> 

0FB6C8 

MOUZX ECX,AL 


85C9 

TEST ECX,ECX 



Looking at the stack now we can see this is about taking the string that corresponds to the 
first of the libraries imported by the program: 


001 

0012FF44 

0012FF48 

0012FF4C 

0012FF50 

0012FF54 

0012FF58 


FFFFFFFF I FFFFFFFF 

actAactccA I aaAaaczA 


00409564 

60226910 
00000100 
00407000 
0040100H 
FFFFFFD1 
0012FF6C 


00409564 ASCII 

I 0rg3 = 6A226910 
LArg4 = 00000100 
crackne_.00407000 
crack ne_.00401000 


’KERNEL32.DLL’' 


Then there is a call to "importerAddNewDII" to add the DLL to the importer of the engine. 

Finally, we finish with a call to "HooksGetTrampolineAddress" what it does is to resolve the 
address of the code that should run natively instead of our hook. This source code is 
hosted on another portion of memory for the engine and is executed immediately after we 
intercepted the DLL loaded, if you look, it assembles a JMP first to the memory area where 
the original code is: 


6H211049 
6021104F 
60211054 
60211059 
6021105C 
60211062 

1-1-35 EUbb22bH 

E8 E60C0100 

2D 63102160 

83E8 05 

8905 64102160 

61 

RUSH UUIUKU RIK U5: LbH22bbbUJ 

COLL <JMP.8,T itanEng ine. HooksQetTrampol ine0ddress> 

SUB EOX,upxHooks.60211063 

SUB EflX 5 

MOU DWORD PTR DS:C60211064],EOX 

POPOD 

crack ne_.WW4W82 

60211063 

- E9 98EF1996 

JMP 003B0000 


4.071 1 

rr 

TNT7 1 


























a\<i 

X 

► 

II 








L 

E 

M 

t[w 

H 

C 


B 

R 

... 

S 


■ — 


? 




)001 


003B000H 

003B0010 

003B0016 

003B0013 

003B0019 

003B001F 

003B0020 

003B0024 

003B0025 

003B002B 

003B002D 

003B0034 


83C7 08 
FF96 4C350000 
FF25 10003B00 
8882 40005748 
F2: RE 
55 

FF25 1F003B00 

97 

8240 00 E9 

98 

1205 00FF252E 
003B 

00B482 40000000 
0000 


ADD EDI,8 

CALL DWORD PTR DS:[ESI+854CI 
JMP DWORD PTR DS:C3B0010] 

MOU BYTE PTR DS:IEDX+48578040],AL 
REPME SCAS BYTE PTR ES:tEOI] 

PUSH EBP 

JMP DWORD PTR DS:C3B001F] 

XCHS EAX,EDI 

ADD BYTE PTR DS:CEAX],-17 
CWDE 

ADC AL,BYTE PTR DS:C2E25FF00I 
ADD BYTE PTR DS:CEBXI,BH 
ADD BYTE PTR DS:CEDX+EAX#4+40I,DH 
ADD BYTE PTR DS:CEAX].AL 


kerne 132. LoadL ibrars; A 
crack ne_.@0408288 


crackme_.@0408297 


There we have the original lines of the program that are the call to LoadLibraryA to resolve 
the DLLs imported by the program. Once that runs, it returns to the instruction following 
the JMP which corresponds to the hook that we placed: 


00408270 

00408272 

00408275 

0040827C 

0040S27E 

00408283 

00408284 

00408285 

00408286 

00408287 

.V 74 3C 
. 8B5F 04 
. 8D8430 10850000 

. 01F3 

.- E9 7D8DE069 

96 

4C 

85 

00 

00 

IsT:EIiI:kI:I:l 

. 95 

18289 

> 8A07 

0040823B 

. 47 

0040S23C 

. 08C0 

0040823E 

74 DC 

00408290 

. 89F9 

00408292 

.- E9 D98DE069 

00408297 

. FF96 50350000 

0040329D 

. 09C0 

0040829F 

.v 74 07 

004082A1 

. 8903 

004082A3 

. 83C3 04 

004032At, 

.* EB El 

004082A8 

> FF96 54850000 

004082AE 

> 61 

004082AF 

.- E9 5C8EE069 


JE SHORT crackne_.004082AE 
MOU EBX,DWORD PTR DS:[ED1+4: 

LEA EAX,DWORD PTR DS:CEAX+ESI+8510] 

ADD EBX,ESI 

JMP upxHooks.6A211000 

DB 96 

DB 4C 

DB SS 

DB 00 

DB 00 _ 

XCHG ERX,EBP 

MOU AL,BYTE PTR DS:CEDI] 

INC EDI 

OR AL, AL _ 

JE SHORT crackne_.0040826C 

MOU ECX,EDI 

JMP upxHooks.6A211070 

CALL DWORD PTR DS:[ESI+8550] 

OR EPX.EAX 

JE SHORT crackne_.004082A8 
MOU DWORD PTR DS:CEBX],EAX 
ADD EBX 4 

JMP SHORT crackkie_. 00408289 
CALL DWORD PTR DS:CESI+8554] 

POPAD 

JMP upxHooks.6A211110 


The next breakpoint stops in what would be the callback to GetProcAddress: 



60 

PUSHOD 



893D FC68226A 

MOU DWORD PTR OS:C602268FC],EDI 


6021107? 

89ID 0069226A 

MOU DWORD PTR DS:C6O226900],EBX 


6O21107D 

68 00010000 

PUSH 100 


60211082 

60 00 

PUSH 0 


60211084 

68 1069226A 

PUSH upxHooks.60226910 

OSCII "KERNEL32.DLL" 

60211089 

E8 B2930000 

COLL upxHooks.60210440 


6021108E 

83C4 0C 

ODD ESP,0C 


60211091 

A1 FC68226A 

MOU EOX,DWORD PTR DS:[602268FC] 


60211096 

3B05 0869226A 

CMP EOX,DWORD PTR DS:C60226908] 

crackne .00400000 

6021109C 

^ 7E 36 

JLE SHORT upxHooks.602110D4 


6021109E 

68 00010000 

PUSH 100 


60211003 

68 1U69226H 

PUSH upxHooks.60226910 

OSCII "KERNEL32.DLL” 

60211008 

8B0D FC682260 

MOU ECX,DWORD PTR DS:C602268FC] 

crackhe .00409564 

602110OE 

51 

PUSH ECX 


602110OF 

FF15 00202260 

COLL DWORD PTR DS:[<&KERNEL32.GetCurrentProcess>] 

k ern e132.Get Cu rren t Process 

602110B5 

50 

PUSH EOX 


602110B6 

E8 730C0100 

COLL < JMP.&TitanEngine.GetRerioteString> 


602110BB 

0FB6D0 

MOUZX EDX,OL 


602110BE 

85D2 

TEST EDX,EDX 


602110C0 

v 74 10 

JE SHORT upxHooks.602110D2 


602110C2 

A1 @0622260 

MOU EOX,DWORD PTR DS:C60226900] 


602110C7 

50 

PUSH EOX 


602110C8 

68 1069226A 

PUSH upxHooks.60226910 

OSCII "KERNEL32.DLL" 

602110CD 

E8 6E0C0100 

COLL <JMP.&TitanEngine.InporterOddNewOPI > 


602110D2 

^ EB 13 

JMP SHORT upxHooks.602110E7 


6O2110D4 

8B0D 00622260 

MOU ECX,DWORD PTR DS:C60226900] 


6O2110DO 

51 

PUSH ECX 


602110DB 

8B15 FC6S226A 

MOU EDX,DWORD PTR DS:C602268FC] 

crackhe .00409564 

602110E1 

52 

PUSH EDX 


602110E2 

E8 5F0C0100 

COLL <JMP.8<T itanEng ine. InporterOddNeuOrdina10PI > 


602110E7 

FF35 E8662260 

PUSH DWORD PTR DS:C602266E8] 

crackhe .00408292 

6O2110ED 

E8 480C0100 

COLL < JMP.&TitanEngine.HooksGetTrar-ipolineOddress> 


602110F2 

2D 01L12160 

SUB EOX,upxHooks.60211101 


602110F7 

83E8 05 

SUB EOX,5 


602110FO 

8905 02112160 

MOU DWORD PTR DS:C60211102],EOX 


60211100 

61 

POPOD 


60211101 

- E9 90909090 

JMP F0B10196 


CClOi 1 i etc 

rr 

INTO 












































































That will do the same job we were doing, calling to "ImporterAddNewApi" both for 
functions that are imported by name and for those that are imported by ordinal. Then, it 
solves the JMP to the original code, jumps and returns to the instruction following the hook 
JMP. 


Finally the last BPX corresponds to the OEP: 




PUSH EBP 


8BEC 

MOU EBP,ESP 

60211113 

83E4 F8 

HMD ESP,FFFFFFF8 

60211116 

83EC 24 

SUB ESP,24 

60211119 

33C0 

XOR EOX.EOX 

602111 IB 

56 

PUSH ESI 

6021111C 

894424 18 

MOU DWORD PTR SS: CESP+18],EOX 

60211128 

894424 1C 

MOU DWORD PTR SS:CESP+1C],EOX 

60211124 

894424 20 

MOU DWORD PTR SS:CESP+20],EOX 

60211128 

894424 24 

MOU DWORD PTR SS:CESP+24],EOX 

6021112C 

894424 08 

MOU DWORD PTR SS:CESP+8],EOX 

60211130 

894424 0C 

MOU DWORD PTR SS:CESP+C].EOX 

60211134 

894424 10 

MOU DWORD PTR SS:CESP+10],EOX 

60211138 

894424 14 

MOU DWORD PTR SS:IESP+14],EOX 

6021113C 

8D4424 18 

LEO EOX,DWORD PTR SS:CESP+18] 

60211140 

50 

PUSH EOX 

60211141 

8D4C24 20 

LEO ECX,DWORD PTR SS:CESP+20] 

60211145 

51 

PUSH ECX 

60211146 

8D5424 2C 

LEO EDX,DWORD PTR SS: CESP+2CI 

60211140 

52 

PUSH EDX 

6021114B 

8BC1 

MOU EOX,ECX 

6021114D 

50 

PUSH EOX 

6021114E 

60 00 

PUSH 0 

60211150 

60 00 

PUSH 0 

60211152 

68 F8672260 

PUSH upxHooks.602267F8 

60211157 

E8 F00B0100 

COLL CJMP.&TitanEngine.Stat LcFLleLoad> 

6021115C 

84C0 

TEST OL,OL 

6021115E 

V 0F84 01010000 

JE upxHooks.60211265 

60211164 

8B0D 08692260 

MOU ECX,DWORD PTR DS:C60226908I 

60211160 

8B35 00202260 

MOU ESI,DWORD PTR DS:[<&KERNEL32.GetCurrentProcess>] 

60211170 

68 ES6Z2260 

PUSH upxHooks.602267F8 

60211175 

51 

PUSH ECX 

60211176 

FFD6 

COLL ESI 

60211178 

50 

PUSH EOX 

60211179 

E8 D40B0100 

COLL < JMP. 8.T L t an En g i n e. Past ePEHeader > 

6021117E 

RR1S F^l^i 7 226H 

MOU EDX,DWORD PTR DS:C602267F4] 

60211184 

01 08692260 

MOU EOX,DWORD PTR DS:C60226908] 

60211189 

52 

PUSH EDX 


Here we perform the same tasks that we studied already when we did the plugin for FUU. 
The unpacked program is dumped here, the IAT is exported; it realigns the PE and we 
search for the overlay to add it, not much to say. 

Now the part that interests me is the one which places the hooks, so let's look a little the 
source code of the DLL to know how to do it. 

Let's start with the main (): 


BOOL APIENTRY DllMain( HMODULE hModule, 

DWORD ul reason^for_call, 
LPVOID IpReserved 


DWORD pOldProtect = PAGE_EXECUTE_READ; 

switch (ul_reason_for_call) 

{ 

case DLL_PROCESS_ATTACH: 

if (!upxHooksInit()){ 
return (false); 

} else { 









VirtualProtect( (void* )((ULONG_PTR)hModule + 
(ULONG^PTR)GetPE32DataFromMappedFile((ULONG^PTR)hModule, NULL, 
UEJ3ECTI0NVIRTUAL0FFSET) ) , 

(size_t)GetPE32DataFromMappedFile((ULONG_PTR)hModule, NULL, 
UE_SECTIONVIRTUALSIZE), PAGE_EXECUTE_READWRITE, SpOldProtect); 
} 

case DLL_THREAD_ATTACH: 
case DLL_THREAD_DETACH: 
case DLL_PROCESS_DETACH: 
break; 

} 

return TRUE; 


We see that when the DLL_PROCESS_ATTACH event (when loading the library) occurs 
the "upxHooksInit" function is called, just that, so let's see what that function does: 


declspec (dllexport) bool stdcall upxHooksInit(){ 
char szUnpackedFile[] = " unpacked.exe"; 
fdLoadedBase = ( long) GetModuleHandleA(NULL); 

fdEntryPoint = (long) GetPE32DataFromMappedFile(fdLoadedBase, NULL, 
UE_OEP) ; 

fdlmageBase = (long) GetPE32DataFromMappedFile(fdLoadedBase, NULL, 
UE^IMAGEBASE); 

GetModuleFileNameA(GetModuleHandleA(NULL), szInputFileName, sizeof 
szInputFileName); 

IstrcpyA(szOutputFileName, szInputFileName); 

RtlMoveMemory(&szOutputFileName[IstrlenA(szOutputFileName) - 4], 
SszUnpackedFile[0], sizeof szUnpackedFile); 
if (upxHookFindPatterns() ) { 

Importerlnit(50 * 1024, fdlmageBase); 
return (true) ; 

}else{ 

return (false) ; 

} 

} 


Well, the first thing is to use GetModuleHandle to get the address where the DLL is 
loaded. Then, it makes several calls to the "GetPE32DataFromMappedFile" function 
asking for several things like OEP and ImageBase. The next important thing is the call to 
upxFiookFindPatterns and following it (after returning from upxFlookFindPatterns) the call 
to "Importerlnit" to start the Importer module of the engine. 

Let's look the "upxFlookFindPatterns" function: 


bool upxHookFindPatterns () { 

upxPatternlAddress = (void* )FindEx(GetCurrentProcess (), 
(void*) (fdLoadedBase + fdEntryPoint), 0x1000, SupxPatternl, sizeof 
upxPatternl, NULL); 





upxPattern2Address = (void* )FindEx(GetCurrentProcess() , 

(void*) (fdLoadedBase + fdEntryPoint), 0x1000, &upxPattern2, sizeof 
upxPattern2, NULL); 

upxPattern3Address = (void*) (FindEx(GetCurrentProcess(), 

(void*)(fdLoadedBase + fdEntryPoint), 0x1000, &upxPattern3, sizeof 
upxPattern3, NULL) + 1); 

if (upxPatternlAddress != NULL && upxPattern2Address != NULL && 
upxPattern3Address != NULL){ 
upxOEPAddress = 

(long) GetJumpDestinationEx(GetCurrentProcess() , 

(ULONG PTR)upxPattern3Address, true) ; 

if (!HooksInsertNewRedirection(upxPatternlAddress, 
SupxHookLoadLibrary, TEE_HOOK_NRM_JUMP)){ 
return (false) ; 

} 

if (!HooksInsertNewRedirection(upxPattern2Address, 
SupxHookGetProcAddress, TEE_HOOK_NRM_JUMP)){ 
return (false) ; 

} 

if (!HooksInsertNewRedirection(upxPattern3Address, 
SupxHookEntryPoint, TEE_HOOK_NRM_JUMP)){ 
return (false) ; 

} 

return (true) ; 

}else{ 

return (false) ; 

} 

} 


Well, let's go by parts. First of all, it uses the "Findex" function to get the address of the 
different necessary patterns, these are GetProcAddress, LoadLibraryA and the OEP as we 
already saw. Once it gets the patterns addresses it uses the "GetJumpDestinationEx" 
function passing as address the one of the pattern that corresponds to the OEP. In this 
way, it gets the OEP address. 

After that, it makes three calls to the "FlooksInsertNewRedirection" function: 


bool stdcall HooksInsertNewRedirection( 
LPVOID HookAddress, 

LPVOID RedirectTo, 
int HookType 


That receives into the "FiookAddress" parameter the address we want to hook, in these 
three cases will be the pattern address of LoadLibraryA, the pattern address of 
GetProcAddress pattern and the OEP address. It also receives the parameter 
"RedirectTo" which is the function address to which we will redirect the flow which are 
each of the functions in which we put a BPX when we were debugging the packed 
program a while ago and finally it receives the kind of hook to place in the parameter 




“HookType” that can be of two types: TEE_HOOK_NRM_JUMP to place a JMP or 
TEE H00K_NRM_CALL to place a CALL. 

The rest is known history, each function will work as we saw when we programmed the 
FUU plugin. 

As you can see, it is a good alternative technique to unpack, maybe a little more 
complicated to implement and debug but it is to have in mind certainly. 

b- Unpacking using Python 

One of the most significant additions to version 2.0.3 of TE is the possibility to access all of 
the SDK API from Python. In this way, you can create scripts of different types either 
unpackers, PE validation tools, lATs reconstructors, etc, in a very simple way. Internally, it 
uses ctypes, the C + + wrapper for Python, in order to do all the hard work of managing 
structures and data types needed to work with WINAPI32 

Let's take a simple example that comes with the SDK to see how to build an unpacker 
from Python with TE. The example is deFSG.py. 

The structure for an unpacker script will generally be as follows: 

1 - Let's define a class and within that class we will define each of the functions that 
we need, most are callbacks that respond to certain events, as we already saw. 

2- Let's define an_init_function that will be responsible to set all callbacks to begin 

execution of the script. 

3- In each callback we will respond to the event we are waiting for. 

This is the basic structure that an unpacker done in Python with TE will have. 

Looking at the code you will understand a little better. 

The first thing to do is to import the library that acts as a link between Python and TE: 

from teSdk import * 

The first thing to do is import the library that acts as a link between Python and TE: 

In my case, I had to do a little modification, I placed the teSdk.py, TitanEngine_x86.dll and 
TitaniumHooks_x86.dll in the Lib\site-packages folder of my Python distribution. 

The only thing I touched in teSdk.py is the following: 

dll name = "TitanEngine x86.dll" 

dll_path = "C:\\Python26\\Lib\\site-packages\\%s" % dll name 

The variable dll_name I named it as the main TE dll, in this case is x86 because I’m in a 
32-bit platform. I made the variable dll_path point to the main DLL path in the Lib\site- 
packages folder in my Python distribution. 
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Once we import the libraries that we need to begin programming the class and its 
methods: 


class deFSG(): 


The first thing we do is to define the_init_of the class where, as you can see, a couple 

of global variables of the class is being assigned a function to be defined later. These are 
the callbacks to be used in every step of the unpacking. For example, by flnitializeDbg we 
are indicating that when the start debugging event session occurs the Onlnitialize function 
is going to be called. Similarly, for example, CbOnOEP will respond when there is a 
breakpoint that will be set later in the OnDbglnit callback. 

def init (self): 

self.CbOnlnitialize = flnitializeDbg(self.Onlnitialize) 


self.CbOnDbglnit 
self.CbOnNext 
self.CbOnOEP 
self.CbOnLLA 
self.CbOnGPA 


= fBreakPoint(self.OnDbglnit) 
= fBreakPoint(self.OnNext) 

= fBreakPoint(self.OnOEP) 

= fBreakPoint(self.OnLLA) 

= fBreakPoint(self.OnGPA) 


self.wild = c_ubyte(0) 

self.iSignatureOffset = 0x14 

self.dllname = create_string buffer(' ' * MAX PATH) 
self.apiname = create_string buffer(' ' * 256) 


TE.EngineCreateUnpackerWindow("[ RL!deFSG ]", "RL!deFSG 2.0", 
"RLldeFSG 2.0", "ReversingLabs Corporation", self.CbOnlnitialize) 

We can also observe, a few variables are declared, but the most important are 
self.dllname and self.apiname since they will be the variables that will contain the packed 
imported DLLs and APIs 

Finally, it calls the EngineCreateUnpackerWindow function which is part of the TE Engine 
module and serves as its name suggests, to create the unpacker main window. 

Now, let’s see each callback and explain a little its operation. The first one is Onlnitialize: 



def Onlnitialize(self, pOriginal, pRealign, pCopyOvl): 


if not pOriginal: return 

We can see that this callback gets three parameters in addition to the self. In pOriginal we 
are going to have the path of the executable that was loaded in the window of unpacker, in 
this case it's being checked to see if the variable has something and if it is an empty string 
then it simply returns .pRealign and pCopyOvl receive a bool type data that indicates 
whether the file needs to be realigned once the unpacking process has finished and if it 
should search for additional information in the original file and add it to the unpacked file, 
respectively. 

self.Input = pOriginal 

self.Output = pOriginal[:len(pOriginal) - 3] + "unpacked" + 
pOriginal[len(pOriginal) - 4:] 


self.Realign = pRealign 
self.Overlay = pCopyOvl 


windll.kernel32.DeleteFileA(self.Output) 


TE.EngineAddUnpackerWindowLogMessage("Unpacker for FSG 2.0 packed 
files") 


TE.EngineAddUnpackerWindowLogMessage("ReversingLabs Corporation / 
www.reversinglabs.com") 

In this part, just a little work environment preparation. First, the file name is “built”, this is 
the name the dumped process will have, then, any previous dumped process with the 
same name is erased and a couple of messages are given to the user by using the 
EngineAddUnpackerWindowLog Message. 

self.Validity = FILE_STATUS_INFO() 

if not TE.IsPE32FileValidEx(pOriginal, UE_DEPTH_DEEP, 
byref(self.Validity)) \ 

or self.Validity.OveralEvaluation != UE RESULT FILE OK: 

TE.EngineAddUnpackerWindowLogMessage("[!] The file seems to be 

invalid.") 


return 

This part checks if the file is a valid PE for which the lsPE32FileValidEx function is called. 
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if self.Validity.FileIs64Bit or self.Validity.FilelsDLL: 


TE.EngineAddUnpackerWindowLogMessage("[!] x86 .exe files are 
supported only.") 

Return 

In this other part is checked whether valid PE file is 32 bits or 64 bits. If the second case is 
given it sends a message to the user that only 32-bit architecture is supported. 

self.Info = TE.InitDebugEx(pOriginal, 0, 0, self.CbOnDbglnit) 
if self.Info: 

TE.EngineAddUnpackerWindowLogMessage("[x] Debugger 
initialized.") 

self.Base = TE.GetDebuggedFileBaseAddress() 

TE.ImporterInit(0x10000, self.Base) 

self.GotTLS = TE.GetPE32Data(pOriginal, 0, 

UE_TLSTABLEADDRESS) 

self.SizeOfImg = TE.GetPE32Data(pOriginal, 0, UE_SIZEOFIMAGE) 

TE.DebugLoop () 

TE.ImporterCleanup() 
else: 

TE.EngineAddUnpackerWindowLogMessage("[!] Could not initialize 
debugging!") 


TE.EngineAddUnpackerWindowLogMessage("[x] Exit Code: 

{0:X}.".format(TE.GetExitCode())) 

The remainder simply initializes the debug session by calling the InitDebugEx function 
passing as callback the CbOnDbglnit function. After initializing the Importer module, 
different executable data is taken such as TLS table, SizeOflmage and image base on 
which the executable was loaded. 

def OnDbglnit(self): 


self.Verify() 




pat = 

(c ubyte * 

5) 

(0x7 5, 

0x03, 

Oxf f, 

0x63, 

0x0c) 



Oxf f, 

11a = 

0x53, 

(c ubyte * 
0x10, 0x95) 

11) 

(Oxeb, 

0x00, 

0x00, 

Oxad, 

0x00, 

Oxad, 

0x50, 

0x00, 

gpa = 

0x33) 

(c ubyte * 

9) 

(0x50, 

0x55, 

Oxf f, 

0x53, 

0x14, 

Oxab, 

Oxeb, 


loc = TE.Find(self.Base, 0x1000, byref(pat), len(pat), 
byref(self.wild)) + 2 

11a = TE.Find(self.Base, 0x1000, byref(11a), len(lla), 
byref(self.wild)) + 7 

gpa = TE.Find(self.Base, 0x1000, byref(gpa), len(gpa), 
byref(self.wild)) + 2 


if loc and 11a and gpa: 

if TE.SetBPX(loc, UE_SINGLESHOOT, self.CbOnNext) and \ 

TE.SetBPX(11a, UE_BREAKPOINT, self.CbOnLLA) and \ 

TE.SetBPX(gpa, UE_BREAKPOINT, self.CbOnGPA): 
return 
else: 

TE.EngineAddUnpackerWindowLogMessage("[!] Could not set a 
breakpoint.") 

else: 

TE.EngineAddUnpackerWindowLogMessage("[!] Could not locate a 
pattern.") 


TE.StopDebug() 


The CbOnDbglnit function simply is what defines the patterns to search and using the Find 
function attempts to find such patterns in the debugged process and when finding one of 
these patterns it simply calls the SetBPX function repeatedly to set breakpoints in places it 
found. Whenever a breakpoint is set a callback is passed that will be in charge of 
responding to the event. Prior to this work, you call the Verify function to determine if the 
file has been loaded as expected for this unpacker: 
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def Verify(self) : 


Sig = self.Base + self.iSignatureOff set 


Magic = c_ulong(0) 
10 = c_ulong(0) 


if windll.kernel32.ReadProcessMemory(self.Info.contents.hProcess, 
Sig, byref(Magic), sizeof(c_ulong), byref(IO)) and Magic.value == 
0x21475346: 


return 


TE.EngineAddUnpackerWindowLogMessage("[!] FSG signature mismatch!") 
TE.StopDebug () 

Just read a few bytes of the process and compares with an expected value which 
determines whether or not the executable is packed with FSG. 

Then we have the callback OnLLA wihich will be invoked when loading packed program 
libraries: 

def OnLLA(self): 

eax = TE.GetContextData(UE_EAX) 

dll = TE.GetRemoteString(self.Info.contents.hProcess, eax, 
cast(self.dllname, POINTER(c_char * MAX_PATH)), MAX_PATH) 


if dll: 

TE.EngineAddUnpackerWindowLogMessage("[x] Loading DLL 
'{0}'.".format(self.dllname.value)) 

TE.ImporterAddNewDll(self.dllname, 0) 

It simply takes the string of the EAX register by calling the GetRemoteString function and 
adds that string with the DLL name to the Importer module calling the ImporterAddNewDll 
function. 

def OnGPA(self): 

eax = TE.GetContextData(UE EAX) 
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edi 


TE.GetContextData(UE EDI) 


api = TE.GetRemoteString(self.Info.contents.hProcess, eax, 
cast(self.apiname, POINTER(c char * 256)), 256) 


TE.EngineAddUnpackerWindowLogMessage("[x] Retrieving API '{0}' at 
thunk {1:08Xformat(self.apiname.value if api else eax, edi)) 

TE.ImporterAddNewAPI(self.apiname.value if api else eax, edi) 

The OnGPA callback performs the same function as OnLLA but with the name and 
address of the imported functions by the packed program. By combining GetRemoteString 
and ImporterAddNewAPI it is completing the entry corresponding to the previous set DLL 
by the OnLLA callback. 

def OnOEP(self): 

oep = TE.GetContextData(UE EIP) 


TE.EngineAddUnpackerWindowLogMessage("[x] OEP found: 
0x{0:08X}.".format(oep)) 


TE.PastePEHeader(self.Info.contents.hProcess, self.Base, 
self.Input) 

if TE.DumpProcess(self.Info.contents.hProcess, self.Base, 
self.Output, oep): 


TE.EngineAddUnpackerWindowLogMessage("[x] Process dumped.") 
TE.MakeAllSectionsRWE(self.Output) 


if not self.GotTLS: 

TE.DeleteLastSection(self.Output) 

TE.EngineAddUnpackerWindowLogMessage("[x] Packer section 

removed.") 


else: 



TE.EngineAddUnpackerWindowLogMessage("[x] Keeping packer 
section due to TLS.") 

if TE.ImporterExportlATEx(self.Output, ".revlabs"): 

TE.EngineAddUnpackerWindowLogMessage("[x] Imports fixed.") 
else: 

TE.EngineAddUnpackerWindowLogMessage("[!] Cannot fix 

imports.") 

TE.StopDebug() 
return 

if self.Overlay: 

if TE.CopyOverlay(self.Input, self.Output): 

TE.EngineAddUnpackerWindowLogMessage("[x] Moving 
overlay to unpacked file.") 

else: TE.EngineAddUnpackerWindowLogMessage("[x] No overlay 

found.") 


if self.Realign: 

if TE.RealignPEEx(self.Output, 0, 0): 

TE.EngineAddUnpackerWindowLogMessage("[x] File has been 

realigned.") 

else: TE.EngineAddUnpackerWindowLogMessage("[!] File 
realigning failed.") 


TE.EngineAddUnpackerWindowLogMessage("[x] File has been 
unpacked to {0}.".format(self.Output)) 


TE.StopDebug () 

The last callback is OnOEP which ends collecting all the data obtained with different 
callbacks and it is responsible for assembling the unpacked executable, dumping the 
process, adding the Imports, giving the appropriate permissions to the sections, realigning 
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the PE in case it is needed, adding additional information, and ending the debugging 
session. 

2- Conclusions 

Throughout the tutorial we have seen some of the functions of TE but that's not all, there 
are many things that can be done using TE such a FUU. We can program in the most 
used languages today and even make scripts that give you incredible power and 
unparalleled ease. 

TE is undoubtedly the option when willing to do an unpacker with no need for self 
programming your own functions. 

Another important thing is that TE is open source and we can contribute to the project with 
code, bugfixes and ideas. 

In my personal experience with TE so far I've had very good results, I've been using it for 
months and I can assure you that it's a very simple developing tool. 
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